作者：jamesob
来源：https://delvingbitcoin.org/t/thoughts-on-scaling-and-consensus-changes-2023/32
今年 6 月，AJ 发表了一篇关于扩展的博客文章，没有得到许多阅读。我在此就草率地转述一下这篇文章 —— 你应该全文阅读 —— 我要指出，他假设了我们可以扩展到 10 亿用户 每周做 1 笔交易的交易处理量（这是支票账户的处理量，也是我个人的目标），办法是拥有 50000 个一定程度上受信任（kinda-sorted-trusted）的链下实体，由这些实体来承担绝大部分的交易处理量。
在这里，我要讨论为什么我认为这是现实的，以及，对可能的共识变更，它是否预示了什么。
链下实体？
如果你想说得格外通俗，你可以直接说 “比特币银行”。我的例子有：
- 一种传统的、联盟化的侧链，比如 Liquid，
- 你将自己的币交给一些第三方来保管，但相应地，你可以得到表达能力更强的脚本编程功能，或者机密资产，或者更快的区块确认速度，以及上述三者在某一些组合。
- Drivechain 也有点像这个，但币的进入（“锚定”）和退出（“脱锚”）是由比特币矿工来处理的。
- 某种类型的 Chaumian ecash 银行，比如 fedimint 和 cashu，
- 你将自己的币交给某个联盟（甚至是个体运营者），然后获得隐私性好处。
- 或是一些尚未被发现的设计，并不需要信任某些第三方会如约归还属于你的资金（即 “脱锚”），相反，你可以依赖于通过智能合约（即，比特币脚本）实现的强制措施，以及，在用户层面，需要一些名为 “时间敏感性” 的魔法香料。
- 比如，coinpool，或者 Ark 这个方向上的某种东西（Ark 自身现在也还只是一个模糊的方向）。
- 你可以认为，它就像闪电通道的泛化，从 2 方变成了 n 方。可能在每一次支付时都需要所有成员的交互，但圣杯就是某一些设计，可以只需要部分乘员参与生成链下活动，而不需要每个人都签名，虽然这到底有没有可能还属开放问题。
- 从本文的角度看，甚至可以是某种 ZKP rollup —— 不管怎么说，“欺诈证明（fraud proof）” 跟 “惩罚交易” 看起来基本上是一样的。（修订：John Light 指出，ZKP rollup 所依赖的 “有效性证明” 并不需要欺诈证明，也不需要活性。）
- 我们将把这些都简称为 “coinpool”。
还有其它选择，比如 spacechain，但我不会在这里介绍其细节。
最后一个选项，也即设想中的 coinpool，似乎显然是更受欢迎的，因为它不依赖于一个受信任的第三方。但它还只是一种设想；而且，即使它可以变成现实了，（就像我们在闪电网络中看到的那样），依然需要一些运营技巧，才能维护一个可用的、能够理解一种 layer 2 协议的节点，保证其可以验证新的活动并且不被女巫攻击，等等。
即使相对懂行的人，也并不一定能运行这样需要实时联网、一旦下线就有可能丢钱的设施。这是一种全职的工作，可能需要多人配合。
Layer 1：不便利
回到正题，在我们设想的扩展场景中，每一个用户都在 3 个或 4 个这样的 准-受信任的/时间敏感型 链下服务处存放了价值，这些服务或多或少就像社区银行。这些 “银行” 可能会以支付通道（或者原子化可互换性）形成网络，这样他们就能处理跨银行的流动性操作，就像电汇一样，即，我想给你支付，但我们在用不同的比特币银行，那么一些实体就可以通过一个闪电网关协助某种类型的批量结算。
在这里，需要大声强调的未言明的部分是，到了 10 亿人想要使用比特币的时候，主链交互会变得非常贵。注意，我说的是 “非常贵”，但不是 “贵到完全不能用”，因为如果用户真的失去了保管 layer 1 实体资产的能力，那比特币就只是用起来摩擦更小的黄金：一个完全基于簿记的市场会产生、比特币所有的好处都会消失，就像 AJ 在自己的文章中说的那样（再放一次链接）。
还要注意，让这些链下构造规矩工作的部分原因是：他们的用户在一定程度商可以跟 layer 1 互动 —— 这是一种威慑。即使在某种 “免信任的” coinpool 中，获得 layer 1 确认的能力也是让它规矩工作的关键。所以，如果 L1 真的变成对绝大部分人都过于昂贵，coinpool 这样的设计也将不能用。也许在一些较贫穷的用户中，在 layer 1 上显现的活动是以小组为单位发生的，这样可以在一群用户中分摊手续费。
这些银行有保持运行（不卷款跑路）的激励，是因为（1）他们可以收手续费；（2？）他们可能受到所在地法律的管辖。但还有一个可取之处在于，比特币的本性，使得每个客户都可以成为一个审计师。
那么，我们先简单假设，在 layer1 上发布一笔交易可能要花费几百元：要是你的 “银行” 出了问题、你需要逃到 layer1 上，这还是可以负担得起的，但并不是所有人每天都可以负担的代价，也显然不是你每个月（甚至每年）都要做一次的事。
我们如何扩展？
我认为，这大概就是比特币能扩展到十亿人的样子：50000 个相互连接的 “银行”，（理想情况下）每个银行都管理着大体上均匀分布的比特币，而每个人都以环绕式结构（hub-and-spoke）使用着少数几个银行。
有没有别的办法？我们没法直接提高区块体积。在一个验证节点所组成的网络上分布着等量的支票活动，这没法让你保持去中心化。
我确实不认为一般人也能运行一个闪电节点（有方向的流动性和在线时间都很烦人），而 Phoenix 这种带有准受信任的 LSP 的模式，就其本身来说也是一种友好的女巫攻击，也依然要求每个人都有有一个 UTXO，这没法扩展到十亿人。假设一个 UTXO 是 41 字节，十亿人意味着 380 GB 的 UTXO 既大小。这会让实时验证变得非常困难，虽然我不了解这个领域，但值得做一些实验。Utreexo 也可以在一定程度上提供帮助，甚至可能是解决这个问题的先决条件。
这种 50000 “银行” 妥协了 layer1 所有权对吗？是的。但整个世界每个人都拥有一个 UTXO —— 除非有什么当前还无法预见的魔法，那我当然支持！—— 是不可能的。至少在比特币的技术背景下，我们可以拥有很好的审计和保管工具，以保证欺诈可以很容易监测到，让盗窃变成基本不可能。
抑郁驿站
在阅读这篇文章的草稿时，我的妻子读到这里就有点灰心了。她问了一个令人骇然的问题，大意是：“要是每个人最终都只能跟侧链交互，不能跟真正的比特币交易，那是不是所有事情都失败了呢？每次你经手的东西都只是一些 token，不是真正的比特币。”
我认为这是一种令人不舒服的真相（uncomfortable realization），我也不喜欢它。我希望结局不是这样的，我希望我们能找出一些很棒的密码学构造，解决去中心化可验证性与交易量之间的矛盾，但我不认为我们应该假定这样的东西会出现。
即使真的走向 “50000 银行”，我认为这是说起来不好听而已。在打败现有金融王朝的同时，我们依然获得了一种无法通胀的基础层货币。有些银行可能会尝试一些小动作，但比特币原生的软件工具会将信任细化为更小的梯度，并且会保证这些小动作更容易被抓到（储备证明？），而且在特定情况下（相对于传统系统）几乎无法欺诈（DLC 去除了经纪人？联合保管？链上可观察性？）。
所以，假设你也愿意接受这些大致的想法，这种架构目标可以给我们一些从短期到长期的比特币开发的启示。
为退出而设计
因为我们可能会看到少数几种占主导的二层（“银行”）设计出现，我们必须考虑相关的故障情形。在审核这篇文章时，Rijndael 称此为 “惊群问题（the thundering herd）”。（译者注：Wiki – Thundering haed problem）
以去年发生的 lnd fiasco 事件为例，它可能导致大量使用 lnd 节点的通道群起关闭。一旦少数可用的 L2 设计走向大众，大规模退出事件发生的概率也随之增加，所以，这似乎是一个需要计划的关键应用场景。
因为 layer 1 的空间是稀缺的，我们需要能够将所有的退出交易都打包到一定事件范围内的区块中。实现这一点的办法似乎将 “退出” 与 “实际申领资金”（即创建新的 UTXO）的操作解耦，这样我们就可以协助尽可能多的参与者及时退出。这或多或少就是一种 “拥塞控制”，这个想法基本上是由 Jeremy Rubin 在 CTV 开发的途中提出来的。
将资金锁定到一条（或者一组）预先指定的路径上以备后续申领，这应该做得尽可能短小，这样在灾难发生的时候，我们就可以安置尽可能多的退出交易。
在这样的场景中，我认为，你不可能获得比裸脚本 <32 byte hash> OP_CHECKTEMPLATEVERIFY 更小的东西了。
值得指出的是，一个 P2TR 的脚本公钥（OP_1 <32 byte pubkey>）的体积与此完全相同，但后面实际花费这个输出时，就会有 17 vB 的开销（(34vB (controlblock) + 33vB (CTV script)) / 4）。如果区块里面都是 2 个输入 1 个输出的 CTV 展开操作，大概 10% 的空间都会花在这上面。
当然，这种开销的负担（比例）会随着你增加输入和输出的数量而减少，所以，为多个用户 “批量处理” 展开操作无法从裸脚本 CTV 中获得很多的好处（相比于 P2TR 的脚本路径）。但当前，最常见的应用场景是闪电通道的关闭：1 个输入 2 个输出。
有一些更加灵活的方案跟 CTV 竞争，比如 OP_TX/OP_TXHASH，还有其它，但从危机引发大量用户从 L2 退出的角度看，灵活性并不是我们所需要的 —— 明智地使用 layer 1 空间才是。所以，无论 OP_TX 等等是否对别的东西有好处（我还不知道有这样的应用场景？），我认为 CTV 就是我们所需要的，因为在区块空间可能很珍贵的时候，它是明确退出链上合约的最精简的方法。
根据一些基本的分析，使用 CTV 的花费压缩（拥塞控制）特性，你可以在危机时刻向一个区块多塞入 33% 的闪电通道退出交易：
src/verystable (init 18a5720) % python examples/txn_size.pyCTV txn: 128vBnon-CTV txn: 171vBCTV txns per block: 31250non-CTV txns per block: 23391more per block with CTV: 33.6%防爆保管模式
我想起的另一个观察是，如果将有大约 50000 个实体，每个都管理着大量的比特币，他们中的许多可能会使用联盟签名器来管理，那就需要一种相对直接的保管模式，让我们非常确定盗窃和丢失是不太可能的。
应该不会让你们感到意外，我认为，OP_VAULT 中的功能就是一个重要部分，因为它启用了 “响应式安全”。如 Jameson Lopp 所说：
使用正确的工具，在密钥失盗中恢复时，我们可以 守株待兔 而不是只能 主动出击。
保险柜合约可以创建一种新的博弈情景。类似于你可以运行瞭望塔，等待尝试欺诈你的闪电通道对手送上门来，你也可以使用瞭望塔来确定没有人攻破了你的比特币保险柜。如果你发现有人已经攻破它了，将资金清扫到安全的地方是非常简单的，甚至可以自动化！
我真诚地相信，每个比特币的自主保管用户、每个钱包开发者，都梦寐以求用户友好的保险柜功能。可以 “追回” 因为安全架构被攻破而失盗的资金，意味着比特币人晚上可以更加安心地入睡，因为他们知道自己可以犯错，不会因为一次疏漏而遭受灾难性的损失。
我认为，可以在链上强制执行的保险柜，可能是成功扩展保管手段、允许出现大量协同式管理的比特币资金池的必要部分。而且 OP_VAULT 似乎是链空间利用效率最高的方式。你也许可以使用，比如说 MATT 来模拟 OP_VAULT 的行为。但我认为，关于 CTV 和拥塞控制的部分已经告诉了我们，常用的操作应该做得尽可能高效（类似于 CISC）。
显然，还有许多因素需要考虑，例如，
- 谁来管理一个瞭望塔，他们可以知道多少信息？
- 灾后复原应该如何设置？高度安全/不便于使用 的密钥、社交恢复？还是两者的某种带有时延的组合？
我很确定还有其它因素。但我不认为，依靠主动式安全可以让那 50000 家心安理得地以自动化方式控制大量资金。即使你可以制作出 HSM 的标准阵列，供应链攻击（包括硬件的和软件的）似乎都非常容易。
其它问题
当然，很多东西我都没有提到。有些东西与限制条款无关，但却与时间敏感型 L2 的运作紧密相关，比如良好的 mempool/手续费 管理对策。没有这个东西，闪电网络就会失败。还有一些让比特币能够抗审查的东西，比如 BIP324。
也应该有人来研究“最小可用的 coinpool”，并弄清楚我们是否需要 taproot 和 CTV 以外的元件。这会是很有价值的信息。
结论
这篇文章已经够长了，我可能会以此为基础，撰写后续的文章，或者使用这个视角来回应其他人的文章。
我认为，除非有什么魔法发明（这我并不指望），我们最终让比特币可以处理支票账户那么大体量的办法，就是使用大约 50000 个实体，通过管理资金池来协助支付流。这些实体将相互形成网络（可能使用闪电网络），并会提供成梯度的信任。来自可以撤退到 L1 的威慑以及竞争对手的 “渗透压”，将让这些东西规矩工作，即使可以肯定这路上会有一些颠簸。
如 Hal 在 2010 年所说的：
实际上，很有理由会存在以比特币为储备的银行，他们将发行自己的电子现金通货，并保证可用这些通货赎回比特币。比特币自身无法扩展到让世界上的每一笔金融交易都被广播给每一个人、打包到区块链上。需要一个比比特币更轻而且效率更高的二层支付系统。类似地，让比特币交易得到确认的时间，对于中大型交易来说也是不现实的。
以比特币为储备的银行将解决这些问题。他们可以像货币国家化之前的银行那样做。不同的银行会提供不同的服务，一些更激进，一些更保守。一些会是部分储备的，但也会有 100% 比特币储备的。利率将各不相同。其中一些银行的现金将比另一些银行的更值钱。
George Selgin 已经详细阐述了银行业自由竞争的理论，而且他主张，这样的系统会是稳定的、抗通胀而且能够自我调节的。
我认为，这就是比特币的最终命运，成为一种可作为银行储备货币的 “高能货币”。大多数比特币交易会在银行间发生，也即结算净 流入/流出。个人之间的比特币交易将很少见 …… 就像今天用比特币来买东西的交易一样。
重要的是，要为他们构建能够支撑他们的层级、给他们提供能够安全和高效开展工作的工具，并且，开发的方式应该让用户有能力审计以及自由迁移。
加上我错过的许多其它东西，这意味着
- 让必要时候退出到 L1 的操作尽可能紧凑和快捷（以应对可能会连锁发生的故障），以及
- 让日常的保管操作安全和简单。
（完）
