长期以来，我一直在思考一个问题：Bitcoin 原生扩容的核心逻辑是什么？
在深入研究闪电网络，并试图在闪电网络上实现非托管业务时，我们感觉到某些方面的不协调。两方通道理论上拥有最强大的交易吞吐量，但是实际维护和使用上的问题却比预期要多得多。闪电网络目前在最初的微支付方向的表现不尽人意，最核心的原因便是流动性。即便当下有大量所谓改善流动性的基础设施被引入，实际效果也仍未达到预期。
就在本文撰写期间，业界知名的闪电自托管钱包 Mutiny Wallet 宣布关闭，随后结束运营的还有其合作的 Liquidity Service Provider（LSP）。自托管钱包与 LSP 的协作模式一直被认为是闪电网络未来的重要方向，这不免让人又一次对其未来充满忧虑。所以，在这个时间点，本文将从流动性扩展的视角，探讨通道网络的演进历程及其未来发展趋势。
比特币的区块容量有限且主网出块时间较长，平均约为 10 分钟，这显然对于其要成为全世界的点对点现金系统的要求来说相差太远。鉴于此，我们迫切需要一个扩容方案：其需要对区块空间占用小、可以快速结算并且必须是一种原生基于比特币的方案。于是，闪电网络应运而生。
闪电网络定义在链上锁定资产后，在链下完成一笔承诺交易的交换即遍算是交易完成，也这是其号称即时支付的原因。这在体验上相对比 Bitcoin 主网支付的确认时间受限 10 分钟而言，对于小额支付场景，无疑是解决了头号问题。
然而，在闪电网络的实际发展和使用过程中，多个问题逐渐浮现，本文在此总结了四个核心问题：
1.1 节点维护难度高
当下的闪电网络基于 P2P 的惩罚交易博弈模型，为了在通道存续期间时刻监控对方是否将不利于自己的旧状态上链，该模型需要 WatchTower 时刻在线，这就需要用户自己维护节点。此外，用户还需要本地保存惩罚私钥和承诺交易数据，导致节点的维护门槛和教育成本都很高。
1.2 高度交互性
在闪电网络中，交互性（interactivity）通常指的是在交易过程中，用户需要进行的一系列交互操作。这些操作往往涉及签名、交换承诺交易、惩罚私钥等。比如，每次在链下状态更新时，交易双方必须同时在线，并签署新的承诺交易进行交换，这对于用户的交互性要求很严苛。并且在多方交互的时候，HTLC、多跳带来的复杂性也难以克服。
1.3 资本效率低
两方通道的 LN-Panelty 机制在某种程度上相当于用户开启自己的银行账户，还需要自带准备金。典型问题就是用户接收资金还需要确保通道流动性，资本效率很低。而且很多处于边缘的通道流动性也不会得到充分利用。
1.4 通道管理成本高
在 P2P 通道中，极其容易出现流动性不平衡的现象，用户不得不依赖各种工具来辅助补充流动性，例如潜水艇互换、通道拼接等。但是这些技术都需要额外的链上交易对原始的 FundingTx 进行调整才能够实现。总的来说，所有的调整手段都代价高昂，特别是在手续费上涨的时候，代价让用户难以忽视。
想象一下，对于那些认为自己在使用 Layer2 技术进行廉价交易的用户，突然面临几笔主网的链上手续费会是怎样一个尴尬的场面。这种尴尬在主网链上手续费变得越高时就越明显，堪称「手续费刺客」。
种种问题在闪电网络的实际采用中也展现出了明显的后果：用户增长乏力，而且新增用户大部分会选择托管方案，从下图中的统计数据中可见一斑。
我们不难理解造成这种情况的缘由，毕竟对于大部分普通用户而言，要求其自行维护节点和通道实在是太困难了。
闪电网络白皮书节选
按照闪电网络白皮书的描述，如果全世界每个人每年都开关两次通道，那么最后需要比特币区块容量增长到 133MB。对比当下的比特币主网，区块大小仅 1MB，即使是使用隔离见证的 P2TR 地址也只有 4MB，可见差距巨大。此外，考虑到实际上对通道流动性的调整的技术 (潜水艇交换，通道拼接) 都需要额外的链上交易，闪电网络面对比特币的区块空间不足的问题在真实场景下则会更加严峻。
可见当下的闪电网络在短期难以满足大规模 C 端用户的需求，此外，受限于比特币区块容量，长期来看闪电网络在扩容方面的潜力也受到显著制约。
问题随之而来：我们究竟需要什么样的比特币链下扩容网络？
为了理解闪电网络当前的局限性，我们需要回溯其设计原理。
当下的闪电网络模型也被称为 LN-Panelty，这个模型通俗来说就是基于惩罚交易的两方通道模型。其安全性依赖于用户本地存储的制衡对方的交易和惩罚私钥，并且要时刻保持对比特币链上的监控，从而保证交易对手方的一举一动都在自己监视之下。
在这样的模型设计下，用户自己运行节点是无法避免的，因为本地存储和 WatchTower 功能不可或缺。前文中已经反复强调了这个部分。
从资本和通信效率的角度看，当下的闪电网络流行的模式是一个 LSP 超级节点在中间提供流动性，然后用户再跟 LSP 维护者的超级节点建立通道，这本身已经背离了最初设想的 P2P 网状模型。在自然演进的情况下，最后还是回到了经典的轴辐模型。
以下图为例，左边是理想的闪电网络，右边则是真实的闪电网络现状。
那么，现在我们设想一下 C 端用户真正所需要的比特币链下扩容网络应具备哪些特性：
1.采用非 P2P 模型，用户无需自行维护节点，同时保持良好的安全性和便捷性
2.在交互端，用户支付时无需同时在线，一方离线、异步操作均可实现
3.提高资本效率，同时满足非托管需求
4.廉价高效的流动性管理机制，甚至无需用户自行维护流动性
基于这些目标，本文将带领读者一同探索比特币链下扩容网络的未来发展方向。
首先我们需要明确，在当前的闪电网络设计的核心机制」LN-Panelty」中，状态更新机制的基础在于：
· 承诺交易的存储与持续监控
· 跨多人协作的多跳机制 (HTLC/PTLC)
这些要素构成了当前闪电网络设计的基础，也直接导致了节点设计的复杂性，表现为：
· 复杂的加密通信交互
· 本地承诺交易和惩罚私钥的存储
· 通道存续期间不能中断运行的 WatchTower
这些问题促使我们思考是否可以采用更轻量的状态更新机制来替代「LN-Penalty」。在这一背景下，BIP118（SIGHASH_ANYPREOUT）作为一种可能的替代方案被提出。
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。
第一个引出 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 模型在多方交互和流动性管理上的局限。
然而，这样一个具备显著优势的方案，至今为何尚未被大规模采用？问题的根源在哪里？
尽管 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 论文诞生多年后，还是属于一个纸上方案。
在前述 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。
总结问题与教训：
1.需要流动性的润滑保证动态面额支付 (可找零交易)：这需要保留通道设计，且同时也可以避免退出问题。
2.减少对所有参与者同步在线的依赖：我们不希望每个用户在链下网络进行任何状态更新的时候都在线，Shared UTXO 的更新应该是相关的人在线协作更新即可。
基于以上认识，本文继续沿着这一方向，探索更优化的方案。
在前面的讨论中，我们认识到不仅需要保留通道的设计，也需要 Shared UTXO 给我们带来链下的低成本收益。那么有一个在闪电网络领域讨论已久的概念进入了我们的视野，即通道工厂（Channel Factory）。
此前，我们提到了被链上 UTXO 承诺的链下 UTXO 被称为 Virtual UTXO。如果把链下的 Virtual UTXO 作为通道的 FundingTx，我们就得到了一个新概念，也就是虚拟通道（Virtual Channel）。那么在这个 Shared UTXO 中链下的虚拟通道由 Virtual HTLC 连接。一切都链下了，全都「虚拟化」了。这似乎提供了一个理想的解决方案：在链下实现大部分功能，包括流动性调整等，闪电网络的扩展似乎迎刃而解了。
但是事实真的如此美好吗？
由于继承了 Shared UTXO 的特性，通道工厂需要多个用户的协同工作来开通和关闭。如果其中任何一个用户无法及时配合（例如离线或不响应），可能会影响整个通道工厂的功能。由于通道工厂涉及多方共同签署状态更新，任何一方的不同步或恶意行为可能导致其他用户无法顺利关闭通道并提取资金。
并且这样的设计的问题也很明显，虽然通过这种方式把通道开关的成本降低了，但是通道之间的安全模型还是依赖承诺交易和 HTLC。因此，通信和交互的问题依旧存在，甚至这种方案的实现复杂性比当下的 LN-Panelty 还要高。
通过之前通道工厂的案例回顾，我们得到一个结论：在基于 Shared UTXO 中的通道设计中，也许并不应该继续沿用经典的「LN-Panelty」的通道设计，但同时应保留引入通道的优点：
1.流动性带来的动态面额；
2.易于退出。
基于此，一种利用 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 的设计相对于闪电网络在用户体验上已经有了惊人的进步：
· 用户无需自行维护节点
· 用户无需自行维护通道流动性，无入账流动性问题
· 支持异步交互，无需双方同时在线
通过上文的研究，我们探索了基于 Shared UTXO 的多个链下扩容方案。Shared UTXO 的设计初衷是为了解决流动性问题，然而，随着协议的不断演进，我们意外地发现它带来了许多我们曾期望但未敢奢望的优势。
这标志着 Bitcoin 链下扩容进入了一个新的发展方向，相较于原有闪电网络的模式，这是一种范式转移：
· 从 P2P 模型到引入无需信任的 operator
链下扩容网络的逻辑从最初 Lightning 网络的「用户对用户」双边博弈模型，逐步演变为「用户与 operator」之间的博弈模式。不同的是，用户无需信任这个第三方的 operator。
· 用户无需自行维护节点设施来保证资产安全
传统的 LN-Penalty 模型以及诸如 CRAB 等最新研究，依赖用户自行提供抵押品以保障资金安全，同时要求用户在通道存续期间保持在线并运行节点。然而，未来的方案将不再需要这些操作。更重要的是，这些流程仍然保持非托管性质，用户始终保有对其资产的控制权。
· 流动性管理职责从用户转移到 operator
在经典的 LN-Penalty 模型和改进设计中，用户需要自行调整通道中的流动性，特别是在流动性不平衡时。这通常需要一定的专业知识，并且在没有 LSP（流动性服务提供商）的帮助下操作复杂。然而，随着流动性管理职责转移到第三方 operator，用户不再需要担忧流动性管理。这极大地简化了用户体验，并且消除了加入网络的障碍。
· 资本效率和潜力极大提升
新的协议设计都在迈向 P2POOL 模型，其在资本效率上与当前的闪电网络存在根本性区别。在 LN-Penalty 模型中，每个用户在开启闪电通道时必须自行提供流动性，但这些通道的流动性大部分时间是闲置的（支付并不频繁发生，且支付不均匀分布于各通道），导致用户的资金未能有效利用。而在新的协议设计趋势中，流动性被集中到流动性池进行统一管理，这为未来的 DeFi 场景提供了无限可能。
这场范式转变表明，流动性管理是 Bitcoin 原生链下扩容演进的本质，也是未来继续演化的核心主线。
未来，随着技术的不断进步和新方案的不断涌现，Bitcoin 的链下扩容之路必将迎来更加光明的发展前景。我们将继续在这一领域进行深入研究，敬请读者期待我们的进一步成果。
参考文献：
· Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. Retrieved from https://lightning.network/lightning-network-paper.pdf
· Decker, C., Russell, R., & Osuntokun, O. (n.d.). Eltoo: A Simple Layer2 Protocol for Bitcoin. Blockstream. Retrieved from https://blockstream.com/eltoo.pdf
· Naumenko, G., & Riard, A. (n.d.). CoinPool: Efficient off-Chain Payment Pools for Bitcoin. Retrieved from https://coinpool.dev/v0.1.pdf
· Delving Bitcoin. (n.d.). LN-Symmetry Project Recap. Retrieved from https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
· Riahi, S., & Litos, O. S. T. (2024). Bitcoin Clique: Channel-free Off-chain Payments using Two-Shot Adaptor Signatures. Cryptology ePrint Archive, Report 2024/025.
· Retrieved from https://eprint.iacr.org/2024/025Dziembowski, S., Fabiański, G., Faust, S., & Riahi, S. (2020). Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma. Cryptology ePrint Archive, Report 2020/175.
· Retrieved from https://eprint.iacr.org/2020/175ARK Network Blog. (n.d.). Retrieved from https://github.com/ark-network/arkdev.info/tree/master/blog
· Somsen, R. (n.d.). Simplest Ark Explanation. Retrieved from https://gist.github.com/RubenSomsen/a394beb1dea9e47e981216768e007454?permalink_comment_id=4633382
· BRQGoo. (2023). Introducing ARK. Medium. Retrieved from https://brqgoo.medium.com/introducing-ark-6f87ae45e272
· JohnLaw2. (n.d.). LN Scaling Covenants. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-scaling-covenants
· JohnLaw2. (n.d.). LN Factory Optimized. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-factory-optimized
· Shinobi. (n.d.). Timeout Trees: A Solution to Scaling Lightning Network LSPs. Bitcoin Magazine. Retrieved from https://bitcoinmagazine.com/technical/timeout-trees-a-solution-to-scaling-lightning-network-lsps
· Rubin, J., & O'Beirne, J. (2020). BIP-119: CHECKTEMPLATEVERIFY. Bitcoin Improvement Proposal. Retrieved from https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
· Black, B. (2023). [bitcoin-dev] Combined CTV APO to minimal TXHASH CSFS. Linux Foundation Mailing List. Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021907.html
· Aumayr, L., Avarikioti, Z., Maffei, M., & Mazumdar, S. (2021). Sleepy Channels: Bitcoin-Compatible Bi-Directional Payment Channels that Do Not Require Monitoring. Cryptology ePrint Archive, Report 2021/1445.
· Retrieved from https://eprint.iacr.org/2021/1445Aumayr, L., Avarikioti, Z., Maffei, M., & Mazumdar, S. (2024). Securing Lightning Channels against Rational Miners. Cryptology ePrint Archive, Report 2024/826. Retrieved from https://eprint.iacr.org/2024/826.pdf
原文链接
| 正加财富网内容推荐 | ||
| OK交易所下载 | USDT钱包下载 | 比特币平台下载 |
| 新手交易教程 | 平台提币指南 | 挖矿方法讲解 |
