比特币网络拥堵怎么办

比特币的网络拥塞情况差异很大。 在交易高峰期，数以千计的交易等待被纳入一个区块，导致手续费暴涨，许多用户仍需等待。 同时，在交易很少的时候，甚至没有足够的交易来填满整个区块，最小的交易费就足以快速确认。

当然，对于需要快速完成大量交易的业务来说，高峰期的网络拥堵是个大问题。 例如，交易所、矿池或发薪服务有时会同时支付数百名用户，这些用户可能急于拿到钱，这是人之常情。 因此，这些服务需要支付高额费用来优先确认这些交易。

现在，Bitcoin Core 开发者 Jeremy Rubin 相信他已经想出如何可靠地缓解网络拥塞，增加比特币在高峰时段的吞吐量。

他的解决方案称为 OP_SECURETHEBAG。

安全包技术（Securing the Bag）

要理解OP_SECURETHEBAG（以下简称“安全包”），我们先从基础开始，通过一个实际的例子。 在这个例子中，有 12 个客户都要求交易所在费用高时提出提款请求。 （实际上，这个数字可能是1200。这里以12个客户为例，更容易说明这个概念。）

即使没有安全袋，交易所也不会愚蠢到创建 12 个单独的交易来分别向每个客户转账。 相反，它创建了一个“批量”交易以节省费用。 一笔交易可能包含3个输入（包括3个“from”对应交易所的消费地址）和12个输出（包括“to”接收地址对应不同的客户）。 在这个例子中，假设输出的金额加上手续费正好等于输入的金额，所以没有零钱地址。

在下图中，左侧是单个交易，右侧是批量交易。

由于批量交易包含许多输出（一对多客户端），因此它们在数据方面非常大。 交易越大，将其打包成区块的成本就越高。 在高峰时段，交易所快速确认交易的成本可能非常高。 （虽然不像12个人交易那么贵，但成本还是很高的。）

交易所也有可能使用较低的费用来节省成本，在这种情况下，交易确认需要一段时间。 但在交易确认之前，客户不确定他们是否真的会收到钱，需要等待：这笔钱可能会被双花，直到交易被写入区块。 这让客户很不高兴，交易所也不愿意。 （在某些情况下，甚至可能不允许让客户等待：例如，当工资单根据合同有义务在特定日期之前确认交易时。）

安全袋的作用就体现在这里。

安全包是提议的“OpCode”——对比特币编程语言的补充。 该操作码实质上告诉交易所将批量交易“拆分”为两笔交易：“支付”交易和“接收”交易。

其中，“支付”交易包含三个原始输入，对应交易所的地址。 但它只包含一个特殊输出。 这个输出称为“提交的输出”，包含一个加密散列：一个看似随机但相对较短的数字串。

这个哈希本质上是一个唯一的序列号，它链接到两个交易中的另一个：“接收”交易。 安全包的关键是“承诺的输出”只能通过这个特定的“支付”交易花费，哈希将两者链接在一起。 （在技术术语中，哈希将提交给整个“接收”交易，除了“prevouts”，这是一个实现细节。）

“接收”交易可以被认为是原始交易的后半部分。 它只包含一个输入（对应于“支付”交易中提交的输出）和所有 12 个输出。 因此，包含所有输出的“接收”交易比“支付”交易大得多。

在下图中，您可以在左侧看到正常的批量交易，在右侧看到两个单独的交易（“支付”和“接收”）。

当交易所向 12 个客户发送付款时，它会广播“支付”和“接收”交易。 但两者之间存在很大差异，而这正是该计划的核心。 较小的“支付”交易包括相对较大的费用以确保快速确认。 由于交易很小，从数据的角度来看，即使是相对较大的费用也不会太多。

相比之下，较大的“接收”交易包含相对较低的费用，这意味着可能需要一段时间才能确认。 但在这里，等待低价交易确认对客户来说并不是什么大问题，因为一旦确认了“支付”交易，就可以保证这笔钱保证对应唯一的“接收”交易。 资金将锚定在区块链中，只能由这少数交易所客户接收。

钱还没有到账……但资金都在妥善保管中。

孩子为父母买单

虽然上面概述的基本示例确保*这 12 家交易所的客户最终获得了他们的资金，但它可能并不能完全满足他们。

（*如果交易费用持续低于预期水平，“接收”交易将不会真正确认自己；这可以通过本文后半部分描述的技巧解决。）

例如，这 12 个交易所客户之一的爱丽丝今天必须向房东支付租金。 在这一点上，仅仅知道她最终会从交易所收到钱是不够的——不管她有多确定（房东不在乎）。 她真正需要的，是能够花费属于她的产出。

这在技术上是可行的。 Alice 可以获取她未确认的输出（12 个中的一个）并立即将其用于新交易。 唯一的问题是：在确认“接收”交易之前，无法确认 Alice 的交易。 同时，房东要求房租今天到账。

幸运的是，爱丽丝可以利用一种古老的比特币技术来确保“接收”交易和她自己的交易都得到确认：“孩子为父母付款”（CPFP）。 基本上，如果 Alice 向房东支付的费用包括足够高的费用，矿工也会被激励将“接收”交易包含在区块中——尽管“接收”交易本身的费用对他们来说意义重大，并不是很有吸引力。 但毕竟只有两笔交易同时被确认，才能拿到Alice的高额交易手续费。

换句话说，加速确认大量数据的“接收”交易的成本将非常昂贵。 这就是交易所首先采用“安全袋”的原因。 此时，Alice 需要分批支付所有 12 个客户的交易手续费，而不是交易所。 但是这样一来，同为顾客的爱丽丝就会觉得很不自在。

幸运的是，安全袋提供了更好的解决方案。

树木付款

为了解决爱丽丝的问题，交易所可以进一步使用“安全袋”这一特殊手段。

在上面的基本示例中，“支付”交易包含一个提交的输出，而“接收”交易包含一个相应的输入和 12 个正常输出。 但实际上比特币确认数几个到账，这 12 个输出可以进一步拆分为更多的“接收”交易。

例如比特币确认数几个到账，“支付”交易可能包括两个提交的输出，对应于两个不同的“接收”交易，每个交易包含六个正常输出。 当然，这意味着快速确认的“支付”交易的交易费用会更高，但爱丽丝要承担一半以上的费用：她只需要承担 5 个其他客户的费用，而不是 11 个。个人。

更好的是，交易所可以在初始“支付”交易和最终“接收”交易之间创建“中间”交易！ 这些“中间”事务每个都包含一个输入和任意数量的已提交输出，可能包括正常输出，从而创建一种树结构。 如此一来，即使是需要即时资金周转的客户，交易所也能合理降低CPFP成本。 充其量，赶时间的客户只需要支付相关的中介交易费用，其他的就不用管了。

如下图所示，交易所可以根据自己的需要选择最合适的方式来创建这种树状交易结构。 （中间步骤越多，一般需要在区块链上确认的总交易数据越多，但每个用户的成本越低。“链式”支付类似于基于树的支付，但更依赖于交易时间顺序。）

细节和实施

本文介绍 Secure the Bag 的基本实现逻辑。 事实上，这个方案可以通过多种方式实现和替换。 例如，Alice 无需使用 CPFP 向房东付款，而是可以通过闪电网络接收资金并立即向房东付款。 还有其他更复杂的解决方案可以加快“接收”交易的速度。

此外，严格来说，该方案中的“安全包操作码”并不是实现两阶段支付解决方案的唯一途径。 即使使用当前的比特币协议，也可以实现类似的事情——但需要所有接收者之间的协调与合作，这在交易所及其客户的例子中很难实现，而且随着更多用户的加入，这样的事情将变得更加困难。 其他解决方案，例如契约合约，需要升级比特币协议才能实施。

实施安全包还需要升级比特币协议，尽管这可以通过向后兼容的软分叉来完成。 提案 Rubin 已经完成了大部分所需的编码工作——代码和想法仍有待审查。 此外，即使提案通过了所有同行评审，协议升级也可能需要一段时间才能被采纳。 因此，现在判断“安全袋”何时正式上线（如果通过）还为时过早。