长期以来，我一直在思考一个问题：Bitcoin 原生扩容的核心逻辑是什么？
在深入研究闪电网路，并试图在闪电网路上实现非托管业务时，我们感觉到某些方面的不协调。两方通道理论上拥有最强大的交易吞吐量，但是实际维护和使用上的问题却比预期要多得多。
闪电网路目前在最初的微支付方向的表现不尽人意，最核心的原因便是流动性。即便当下有大量所谓改善流动性的基础设施被引入，实际效果也仍未达到预期。
就在本文撰写期间，业界知名的闪电自托管钱包 Mutiny Wallet 宣布关闭，随后结束运营的还有其合作的 Liquidity Service Provider（LSP）。自托管钱包与 LSP 的协作模式一直被认为是闪电网路未来的重要方向，这不免让人又一次对其未来充满忧虑。
所以，在这个时间点，本文将从流动性扩展套件的视角，探讨通道网路的演进历程及其未来发展趋势。
1. 当前闪电网路的问题是什么？
比特币的区块容量有限且主网出块时间较长，平均约为 10 分钟，这显然对于其要成为全世界的点对点现金系统的要求来说相差太远。鉴于此，我们迫切需要一个扩容方案：其需要对区块空间占用小、可以快速结算并且必须是一种原生基于比特币的方案。于是，闪电网路应运而生。
闪电网路定义在链上锁定资产后，在链下完成一笔承诺交易的交换即遍算是交易完成，也这是其号称即时支付的原因。这在体验上相对比 Bitcoin 主网支付的确认时间受限 10 分钟而言，对于小额支付场景，无疑是解决了头号问题。
然而，在闪电网路的实际发展和使用过程中，多个问题逐渐浮现，本文在此总结了四个核心问题：
1.1 节点维护难度高
当下的闪电网路基于 P2P 的惩罚交易博弈模型，为了在通道存续期间时刻监控对方是否将不利于自己的旧状态上链，该模型需要 WatchTower 时刻线上，这就需要使用者自己维护节点。此外，使用者还需要本地储存惩罚私钥和承诺交易资料，导致节点的维护门槛和教育成本都很高。
1.2 高度互动性
在闪电网路中，互动性（interactivity）通常指的是在交易过程中，使用者需要进行的一系列互动操作。这些操作往往涉及签名、交换承诺交易、惩罚私钥等。比如，每次在链下状态更新时，交易双方必须同时线上，并签署新的承诺交易进行交换，这对于使用者的互动性要求很严苛。并且在多方互动的时候，HTLC、多跳带来的复杂性也难以克服。
1.3 资本效率低
两方通道的 LN-Panelty 机制在某种程度上相当于使用者开启自己的银行帐户，还需要自带准备金。典型问题就是使用者接收资金还需要确保通道流动性，资本效率很低。而且很多处于边缘的通道流动性也不会得到充分利用。
1.4 通道管理成本高
在 P2P 通道中，极其容易出现流动性不平衡的现象，使用者不得不依赖各种工具来辅助补充流动性，例如潜水艇互换、通道拼接等。但是这些技术都需要额外的链上交易对原始的 FundingTx 进行调整才能够实现。总的来说，所有的调整手段都代价高昂，特别是在手续费上涨的时候，代价让使用者难以忽视。
想像一下，对于那些认为自己在使用 Layer2 技术进行廉价交易的使用者，突然面临几笔主网的链上手续费会是怎样一个尴尬的场面。这种尴尬在主网链上手续费变得越高时就越明显，堪称 「手续费刺客」。
种种问题在闪电网路的实际采用中也展现出了明显的后果：使用者增长乏力，而且新增使用者大部分会选择托管方案，从下图中的统计资料中可见一斑。
新增加的闪电网路使用者选择使用托管钱包方案和非托管钱包方案的数量统计
我们不难理解造成这种情况的缘由，毕竟对于大部分普通使用者而言，要求其自行维护节点和通道实在是太困难了。
2. 我们需要什么样的比特币链下扩容网路？
闪电网路白皮书节选
按照闪电网路白皮书的描述，如果全世界每个人每年都开关两次通道，那么最后需要比特币区块容量增长到 133MB。对比当下的比特币主网，区块大小仅 1MB，即使是使用隔离见证的 P2TR 地址也只有 4MB，可见差距巨大。
此外，考虑到实际上对通道流动性的调整的技术 (潜水艇交换，通道拼接) 都需要额外的链上交易，闪电网路面对比特币的区块空间不足的问题在真实场景下则会更加严峻。
可见当下的闪电网路在短期难以满足大规模 C 端使用者的需求，此外，受限于比特币区块容量，长期来看闪电网路在扩容方面的潜力也受到显著制约。
问题随之而来：我们究竟需要什么样的比特币链下扩容网路？
2.1 闪电网路的现状
为了理解闪电网路当前的局限性，我们需要回溯其设计原理。
当下的闪电网路模型也被称为 LN-Panelty，这个模型通俗来说就是基于惩罚交易的两方通道模型。其安全性依赖于使用者本地储存的制衡对方的交易和惩罚私钥，并且要时刻保持对比特币链上的监控，从而保证交易对手方的一举一动都在自己监视之下。
在这样的模型设计下，使用者自己执行节点是无法避免的，因为本地储存和 WatchTower 功能不可或缺。前文中已经反复强调了这个部分。
从资本和通讯效率的角度看，当下的闪电网路流行的模式是一个 LSP 超级节点在中间提供流动性，然后使用者再跟 LSP 维护者的超级节点建立通道，这本身已经背离了最初设想的 P2P 网状模型。在自然演进的情况下，最后还是回到了经典的轴辐模型。
以下图为例，左边是理想的闪电网路，右边则是真实的闪电网路现状。
2.2 理想的 to C 链下扩容网路的特性
那么，现在我们设想一下 C 端使用者真正所需要的比特币链下扩容网路应具备哪些特性：
- 采用非 P2P 模型，使用者无需自行维护节点，同时保持良好的安全性和便捷性
- 在互动端，使用者支付时无需同时线上，一方离线、非同步操作均可实现
- 提高资本效率，同时满足非托管需求
- 廉价高效的流动性管理机制，甚至无需使用者自行维护流动性
基于这些目标，本文将带领读者一同探索比特币链下扩容网路的未来发展方向。
3. BTC 原生扩容演进之路
首先我们需要明确，在当前的闪电网路设计的核心机制」LN-Panelty」 中，状态更新机制的基础在于：
- 承诺交易的储存与持续监控
- 跨多人协作的多跳机制 (HTLC/PTLC)
这些要素构成了当前闪电网路设计的基础，也直接导致了节点设计的复杂性，表现为：
- 复杂的加密通讯互动
- 本地承诺交易和惩罚私钥的储存
- 通道存续期间不能中断执行的 WatchTower
这些问题促使我们思考是否可以采用更轻量的状态更新机制来替代 「LN-Penalty」。在这一背景下，BIP118（SIGHASH_ANYPREOUT）作为一种可能的替代方案被提出。
3.1 LN-Symmetry：状态更新引入版本机制
BIP118 提议引入 SIGHASH_ANYPREOUT 签名模式，它允许交易的输入无需完全指定前一个输出，并且在不改变签名的情况下更新其前序交易。这样的设计相对 「LN-Penalty」 就可以显著降低节点之间的加密通讯复杂度和储存需求。SIGHASH_ANYPREOUT 源自论文 eltoo: A Simple Layer2 Protocol for Bitcoin，在最近的闪电网路开发讨论中，基于该改进的闪电网路模型也被称为 「LN-Symmetry」。
虽然 LN-Symmetry 降低了本地承诺交易储存的压力，但是它并未完全消除监控需求。尽管 Eltoo 不需要交换承诺交易和私钥签名，但如果某个参与者尝试将旧状态释出到链上，另一方仍需即时监控，并及时释出最新的状态交易以替换旧状态。
这个过程中的监控任务仍然需要传统的 WatchTower，此时执行 WatchTower 的目的从惩罚变成了状态替换。使用者依旧需要维护自己的节点。
同时，LN-Symmetry 依然需要 HTLC/PTLC 等机制来保证多人协作，这仍然会同过去的闪电网路节点设计一样，有很严重的通讯负担。
所以，从整体效果来看，LN-Symmetry 给当下闪电网路的体验改进是有限的，距离我们追求的目标还有很长的路要走。
为了进一步的改进，本文引出了下一阶段的方向：Shared UTXO。
3.2 CoinPool ：降低多方通道的互动性和流动性需求
第一个引出 Shared UTXO 概念的论文即是 CoinPool: efficient off-chain payment pools for Bitcoin，其核心目标是在 SIGHASH_ANYPREOUT 的版本更新机制下进一步解决多方互动的问题。
在 LN-Symmetry 设计中，通过 Eltoo 引入的新的状态更新机制，的确简化了点对点通道的状态管理。然而，当涉及到多方协作时，互动的复杂性仍然存在，尤其是在多跳支付（HTLC/PTLC）中，需要各方的密切协调，并多次加密通讯。
CoinPool 的创新之处在于，它利用 Shared UTXO 模型，允许多方在同一个带有版本控制的 UTXO 上协作。通过这种方式，多个参与者可以在不依赖复杂的 HTLC/PTLC 机制的情况下，共同承诺并管理一个 UTXO 的状态。其主要优势体现在：
- 大幅降低多方通道的互动复杂性：由于所有参与者都共享同一个 UTXO，他们可以通过对该 UTXO 的版本更新进行签名来达成共识，而无需进行多次的链上交易或复杂的链下互动。这种简化使得多方通道的管理变得更加高效。
- 链下更新机制变得更为直接：在这种设计下，链下的状态更新机制转变为由多方共同签名确认某个版本的 UTXO。这种方法不仅简化了状态更新的流程，还进一步减少了各方之间的依赖性和潜在的冲突点。
- 消除独立流动性需求：通过 Shared UTXO 模型，多个参与者实际上共享了同一个流动性池，无需每个参与者独立维持足够的流动性。在多方协作的 CoinPool 设计中，流动性需求可以被大幅度削减或重新分配。参与者可以利用共享 UTXO 中的流动性来完成支付，而不必各自为自己的通道锁定大量资金。这不仅提高了资金利用效率，还减少了个体参与者的资金压力。
CoinPool 的设计通过共享 UTXO 的方式，成功地将多方通道中的互动复杂性降至合理水平，同时维持了系统的安全性和高效性。更重要的是，它减少了对每个参与者独立流动性需求的依赖，为多方协作提供了一种更轻量、更灵活的解决方案，突破了传统 LN 模型在多方互动和流动性管理上的局限。
然而，这样一个具备显著优势的方案，至今为何尚未被大规模采用？问题的根源在哪里？
3.3 为什么 CoinPool 没有真正实施？
尽管 CoinPool 拥有众多优点，并被视为一种理想扩容模型，但是其依赖的软分叉升级要求太多，以至于我们在有生之年都可能看不到其在比特币网路上落地。CoinPool 对软分叉升级的需求主要集中在以下两个方面：
3.3.1 状态更新机制升级
由于 CoinPool 是基于 Eltoo 设计的，继承了其对状态更新机制对软分叉的需求，即需要比特币升级启用一个新的签名模式 SIGHASH_ANYPREVOUT (APO)，但众所周知，比特币软分叉升级进展缓慢，使得 CoinPool 的状态更新机制依赖的技术难以应用于现实。
3.3.2 Shared UTXO 需要契约简化操作机制
正如前文所述，Shared UTXO 每次状态的更新都需要收集所有共享该 UTXO 某个版本的签名。在这个过程中，如果有一方掉线，那么整个系统将会陷入停滞，用区块链术语来说就是这样的系统活性（liveness）很差。 为了克服这一挑战，系统需要一种可以以较低成本且不完全依赖合作更新 Shared UTXO 的机制。
CoinPool 论文中，提出了 OP_MERKLESUB，旨在通过默克尔树结构来验证并更新特定参与者的状态。虽然这一设计思路具有理论上的可行性，但它与其他基于默克尔树的操作契约面临相似的问题，即逻辑实现复杂，且难以形成通用、可复用的契约。比如类似 **OP_TAPLEAFUPDATEVERIFY (TLUV)** 的契约等等。此外，OP_EVICT 这类直接把不合作的一方踢出 Shared UTXO 的契约功能则过於单一，难以预见其能顺利通过比特币网路的升级。
在这些契约提案中，OP_CheckTemplateVerify (CTV) 逐渐成为关注的焦点。与直接构建和验证一个默克尔树不同，CTV 则是通过预定义交易的模版来进行支出限制。CTV 不仅实现简单，还可以通过一个交易的承诺链条将一系列链下的 UTXO 通过一个链上的 UTXO 进行承诺。而这些被链上承诺的链下 UTXO 就是 Virtual UTXO 概念的最初起源。
在这些契约中，CTV 的普及呼声最大，因为其既简单又通用。CTV 强大的能力不仅可以实现类似 CoinPool 的想法，更是可以为 Rollup 所用。可以想像每次通过 OP_CAT 进行 ZKP-MerkleState 验证，并且在指令码中直接承诺对应 Layer2 状态的 Shared UTXO，我们将可以构建真正意义上的比特币 ZK-Rollup 方案。
综上所述，CoinPool 的实施面临的主要问题就在于需要轻量的状态更新机制 APO 和 Shared UTXO 的操作码来帮助进行实现，而这两者均需要比特币的软分叉升级。以至于 CoinPool 论文诞生多年后，还是属于一个纸上方案。
3.4 Bitcoin Clique：链下抗双花原语 2-AS
在前述 CoinPool 模型的讨论中，我们了解到，其依赖的 APO 机制需要进行软分叉升级才能让方案得以实现，这在短期内难以达成。那么如果有一种不依赖比特币软分叉升级的新的链下防双花的原语，那么实现的问题会在很大程度上得到解决。
SIGHASH_ANYPREVOUT 核心作用是提供的是一种可以避免双花的链下状态更新机制。基于这一思路，如果能找到等效的密码学原语，就可以解决链下状态更新的问题，还可以避开比特币操作原语的更新需求。Bitcoin Clique 这篇论文的出现带来了新曙光。它引入了一个全新的密码学原语，2-shot-adaptor-signature（2-AS），为链下防双花提供了新的解决方案。
2-AS 是基于 Schnorr adaptor signature 的密码学原语，要理解 2-AS，我们首先要对 Schnorr 签名和介面卡签名有一定了解。
3.4.1 Schnorr 签名
Schnorr 签名具有线性属性，这意味著多个签名可以聚合成一个签名。简单来说，若有多个签名 $S_1$ 和 $S_2$，可以通过加法聚合成一个签名 $S=S_1+S_2$，而验证时对应的公钥也可以聚合成 $P = P_1 + P_2$。
3.4.2 介面卡签名
介面卡签名有几个基本的步骤，如 Gen、PSign、PVrfy、Adapt、Extract。在理解 2-AS 时，尤为重要的是理解 Psign 和 Extract 这两个步骤。
本文著重从用途而非密码学上去理解介面卡签名。简而言之，当两个主体希望合作确认一笔签名时，往往通过对方的介面卡来作为签名的一部分，而介面卡往往是公私钥中的公钥部分，然后持有该介面卡对应私钥也就是所谓秘密的一方拥有可以 Adapt 补全 Psign 留下的部分签名的能力。
如果仅仅是这样的话，和 MuSig 是不是差不多？但是介面卡签名独特之处在于可以 Extract，也就是当完整的签名被释放后，当初发起介面卡签名的 Psign 的一方可以通过完整的签名、之前的部分签名以及介面卡（公钥）提取出对应的秘密（私钥 ）。
3.4.3 两者结合：2-AS
前面已经了解 Schnorr 签名和介面卡签名的特性，现在我们就可以看看将两者结合的魔法：2-AS。
假定我们有一个 VTXO，并且希望在链下能保证其在双花的时候能被罚没，那么我们可以这样设计：
首先我们要有一个惩罚输出，其中能解锁的 pubkey 是一个惩罚公钥。保证使用者在进行双花的时候能够进行罚没。
交易对手之间合作进行介面卡签名确认链下交易，如果使用者两次使用同一个输入，那么该输出能被服务商罚没。
要求使用者每次在更新状态的时候都需要生成一个 pubkey 作为惩罚输出，该惩罚输出的惩罚公钥由提前确定好的两对公钥进行 Schnorr 签名技术加法所构成。
所以我们每次交易前都确认好随后使用的公私钥对，提前生成惩罚输出。那么一旦双花发生，服务商就可以通过两次介面卡签名最终得到对应惩罚输出的私钥。
3.4.4 Bitcoin Clique 的利弊
Bitcoin Clique 方案也并非完美无缺。其缺点在于，在链下状态更新时，需要不断交换用于构建新的惩罚公钥的 2-AS 金钥。并且由于该方案基于 CoinPool 设计，同时为了每次交换 2-AS 金钥和对新版本的 UTXO 进行校验签名，该方案也要求状态更新时所有人线上。 也就是说通讯的复杂度和互动性依旧很高。
最重要的一点就是这样的模型是一种类似 StateChain 的设计，每次我们在链下转移的是某个 UTXO 的所有权，所以使用类似 2-AS 的 double-spend-prevent signatures 的系统都无法在链下支付中进行找零，这就让应用场景非常有限。
此外，即便是有了便于操作的 SharedUTXO 机制和不需要软分叉的链下防双花原语，我们仍需要所有人线上更新确认 UTXO 的新状态，即使是每次状态更新只影响链下网路中的一部分人。让不相关的人线上参与链上更新是不合理的。
并且完全消除流动性需求也不是我们所期望的，缺乏流动性润滑的支付方案无法进行面额找零，且由于退出问题，所有人的面额往往必须相同。
因此，目前不存在一个非通道且支援动态面额并基于 UTXO 的链下扩容方案。曾经以太坊也在这个路线上饱受困扰，我们称之为 Plasma 陷阱，相关的研究可以参考论文 Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma。
总结问题与教训：
- 需要流动性的润滑保证动态面额支付 (可找零交易)：这需要保留通道设计，且同时也可以避免退出问题。
- 减少对所有参与者同步线上的依赖：我们不希望每个使用者在链下网路进行任何状态更新的时候都线上，Shared UTXO 的更新应该是相关的人线上协作更新即可。
- 基于以上认识，本文继续沿著这一方向，探索更优化的方案。
3.5 通道工厂和虚拟通道
在前面的讨论中，我们认识到不仅需要保留通道的设计，也需要 Shared UTXO 给我们带来链下的低成本收益。那么有一个在闪电网路领域讨论已久的概念进入了我们的视野，即通道工厂（Channel Factory）。
此前，我们提到了被链上 UTXO 承诺的链下 UTXO 被称为 Virtual UTXO。如果把链下的 Virtual UTXO 作为通道的 FundingTx，我们就得到了一个新概念，也就是虚拟通道（Virtual Channel）。
那么在这个 Shared UTXO 中链下的虚拟通道由 Virtual HTLC 连线。一切都链下了，全都 「虚拟化」 了。这似乎提供了一个理想的解决方案：在链下实现大部分功能，包括流动性调整等，闪电网路的扩展套件似乎迎刃而解了。
但是事实真的如此美好吗？
由于继承了 Shared UTXO 的特性，通道工厂需要多个使用者的协同工作来开通和关闭。如果其中任何一个使用者无法及时配合（例如离线或不响应），可能会影响整个通道工厂的功能。由于通道工厂涉及多方共同签署状态更新，任何一方的不同步或恶意行为可能导致其他使用者无法顺利关闭通道并提取资金。
并且这样的设计的问题也很明显，虽然通过这种方式把通道开关的成本降低了，但是通道之间的安全模型还是依赖承诺交易和 HTLC。因此，通讯和互动的问题依旧存在，甚至这种方案的实现复杂性比当下的 LN-Panelty 还要高。
3.6 ARK JoinPool 和临时通道
通过之前通道工厂的案例回顾，我们得到一个结论：在基于 Shared UTXO 中的通道设计中，也许并不应该继续沿用经典的 「LN-Panelty」 的通道设计，但同时应保留引入通道的优点：
- 流动性带来的动态面额
- 易于退出
基于此，一种利用 JoinPool 的临时通道的设计应运而生，即 ARK Protocol。
3.6.1 JoinPool：部分人参与更新
在如前文所述，CoinPool 给多人的链下协作扩容带来的潜力，比如不需要流动性、多跳、HTLC 等复杂并且容易出故障的设计。
但是 CoinPool 模型最关键的问题就是对使用者的线上要求：整个 Shared UTXO 中的使用者在链下状态更新时都必须线上，即便部分使用者的状态没有改变，依然需要线上验证并给出对应的签名。这一要求让我们始终无法避免使用者需要执行自己节点的问题。
为了解决这一难题，一种新的模型被提出，即 JoinPool。JoinPool 在 Shared UTXO 之中的理念是：每次有使用者需要更新其链下状态时，大家一起加入到一个代表其对应 UTXO 新状态的 Shared UTXO 之中。
这就解决了不相关的使用者在他人执行时也需要线上的问题。也就是说，在基于 JoinPool 的设计中，使用者仅在需要进行交易时才需线上。
但是我们都明白，需要不间断执行闪电网路节点除了需要保证使用者私钥线上可以进行签名外，还有一个重要的原因是，每个通道成员都需要 WatchTower 持续监视交易对手方是否把对自己不利的承诺交易到链上。这引出了我们需要解决的第二个问题。
3.6.2 WatchTower 职责转移：使用者无需自行维护节点
在经典的 LN-Panelty 的设计中，每个使用者需要构建自己的 WatchTower 来监控对方是否把旧的状态上链，若是则会进行惩罚。在这样的旧模型中，我们所有人的交易对手方都是对等的闪电节点，每次参与交易都有可能是和不同的节点开启通道进行交易。但是在 ARK 中，所有的使用者其实都是和 ASP（ARK Service Provider）互动，并不会直接和别的使用者互动。
对于 ASP 来说，使用者在链下的 VTXO 一经交易，就会签署一份弃权交易。这是因为理想情况下使用者在链下的 VTXO，是不会被提到链上的，而是不断被引用再进行到下一轮交易之中。
若是一份 VTXO 在链下被交易，同时在链上被提出，这就代表著这个 VTXO 被使用者进行了双花交易，那么 ASP 就会用该使用者当初链下签署的弃权交易来对该使用者提到链上的资金进行罚没。ASP 会对历史上所有出现的 VTXO 进行监控，防止有人从链下已经花费的 VTXO 中再到链上恶意退出。
这就将 WatchTower 的运营责任从普通使用者转移到了 operator，相对于闪电网路而言，这种模式有了一个巨大的改进：我们终于不再需要普通使用者执行自己的节点来保障自己的安全。
关于其他方案在优化使用者节点执行方面的小结：
闪电网路节点云托管
一些方案选择在云平台上执行闪电网路节点，以帮助使用者降低执行节点的使用门槛。然而，这种方案从本质上违背了闪电网路本身的安全假设。在闪电网路技术中，私钥和承诺交易的储存在许多场景中同样重要。因此，简单地使用远端私钥并不能保证安全。
本质上，这种方案将两方博弈场景变成了一个涉及我、交易对手方和云托管方的三方博弈场景。自己在与对手方交易后但状态尚未上链的状态时，云托管方可以单方面删除我云端节点中的承诺交易，此时我的交易对手方便可将对其有利的状态上链。 在这样的闪电网路云节点托管方案中，存在云托管平台和交易对手方串通作恶的风险。
CRAB 和 Sleepy CRAB
Aumayr 等人提出的 CRAB (Channel Resistant Against Bribery) 协议，通过额外新增抵押品结合激励矿工的机制来保障支付通道的安全，尤其是在使用者离线的情况下。这种机制减少了对第三方 WatchtTower 的依赖。然而，这种抵押品机制无疑进一步加剧了类似 「入帐流动性」 的问题。因为它需要使用者在加入链下网路时，锁定更多与交易目的无关的资金，虽然确保了安全性，但牺牲了资金的流动性和效率。并且该类方案仍需要使用者自行执行节点，只是降低了对使用者线上的要求。
3.6.3 临时通道：使用者无需自行维护通道流动性
有人可能会问，为什么 ASP 服务商愿意为我们在 JoinPool 的通道注入流动性？这是因为使用者如果想使用基于 ARK 网路的 VTXO，必须先将自己的 UTXO 与运营商一起存入一个多签地址，其类似于一个 FundingTx，以换取 VTXO。本质上，使用者每次链下交易都是在使用 opeator 的资金，但是会出让此前自己此前和 opeator 多签的资金。
而之所以把 ARK 的通道称为一种临时通道，是因为它具有单向性和一次性注资两种特点。
- 单向性：在单向通道内，资金只会从指定发起方转入对应的输出方。
- 一次性注资：ARK 的通道只需要一次性注入资金。资金注入后，不需要继续维护通道的流动性。
在这样的临时通道的设计下，注资完成之后，通道不需要再进行再平衡等调整。相对于闪电而言，不仅使用者不再需要关心通道流动性，流动性提供者也不再需要维护通道流动性。通道中唯一存在的变动只剩下了使用者退出这一事件。
3.6.4 ARK 协议的总结
综合以上所述，我们可以清晰地看到，ARK Protocol 的设计相对于闪电网路在使用者体验上已经有了惊人的进步：
- 使用者无需自行维护节点
- 使用者无需自行维护通道流动性，无入帐流动性问题
- 支援非同步互动，无需双方同时线上
4. Bitcoin 原生扩容架构的改变
通过上文的研究，我们探索了基于 Shared UTXO 的多个链下扩容方案。Shared UTXO 的设计初衷是为了解决流动性问题，然而，随著协议的不断演进，我们意外地发现它带来了许多我们曾期望但未敢奢望的优势。
这标志著 Bitcoin 链下扩容进入了一个新的发展方向，相较于原有闪电网路的模式，这是一种正规化转移：
从 P2P 模型到引入无需信任的 operator
链下扩容网路的逻辑从最初 Lightning 网路的 「使用者对使用者」 双边博弈模型，逐步演变为 「使用者与 operator」 之间的博弈模式。不同的是，使用者无需信任这个第三方的 operator。
使用者无需自行维护节点设施来保证资产安全
传统的 LN-Penalty 模型以及诸如 CRAB 等最新研究，依赖使用者自行提供抵押品以保障资金安全，同时要求使用者在通道存续期间保持线上并执行节点。然而，未来的方案将不再需要这些操作。更重要的是，这些流程仍然保持非托管性质，使用者始终保有对其资产的控制权。
流动性管理职责从使用者转移到 operator
在经典的 LN-Penalty 模型和改进设计中，使用者需要自行调整通道中的流动性，特别是在流动性不平衡时。这通常需要一定的专业知识，并且在没有 LSP（流动性服务提供商）的帮助下操作复杂。然而，随著流动性管理职责转移到第三方 operator，使用者不再需要担忧流动性管理。这极大地简化了使用者体验，并且消除了加入网路的障碍。
资本效率和潜力极大提升
新的协议设计都在迈向 P2POOL 模型，其在资本效率上与当前的闪电网路存在根本性区别。在 LN-Penalty 模型中，每个使用者在开启闪电通道时必须自行提供流动性，但这些通道的流动性大部分时间是闲置的（支付并不频繁发生，且支付不均匀分布于各通道），导致使用者的资金未能有效利用。而在新的协议设计趋势中，流动性被集中到流动性池进行统一管理，这为未来的 DeFi 场景提供了无限可能。
这场正规化转变表明，流动性管理是 Bitcoin 原生链下扩容演进的本质，也是未来继续演化的核心主线。
未来，随著技术的不断进步和新方案的不断涌现，Bitcoin 的链下扩容之路必将迎来更加光明的发展前景。我们将继续在这一领域进行深入研究，敬请读者期待我们的进一步成果。
