译者：简单来讲，就是对交易进行延迟满足，或许这个也是比特币的跨链切入口之一

比特币的网络拥塞情况千差万别。在交易高峰期时，成千上万的交易在等待被打包入块，从而导致手续费飙升，许多用户仍不得不等待。与此同时，在交易较少的时候，甚至没有足够的交易来填满整个区块，最小的手续费就足以快速确认。

当然，对于需要快速完成大量交易的服务来说，高峰时段的网络拥塞是一个大问题。例如，交易所、矿池或工资单服务有时会同时向数百名用户付款，而这些用户可能会迫不及待地想拿到钱，这是人之常情。因此，这些服务需要支付高昂的费用，才能将这些交易优先得到确认。

现在，比特币核心开发者Jeremy Rubin认为，他已经找到了如何可靠地缓解网络拥塞的方法，可以提高高峰时段比特币的吞吐量。

他的解决方案被称为 OP_SECURETHEBAG。

安全袋技术（Securing the Bag）

要了解OP_SECURETHEBAG（下面简称为“安全袋”），让我们以一个实际的示例为例，从基础入手。在此示例中，有12个客户都要求交易所在手续费较高的时候发出提现请求。（实际情况中，这个数字可能会是1200个，这里以12个客户为例是为了更容易解释概念。）

即使没有安全袋，交易所也不会那么傻的创建12笔单独的交易来分别向每个客户转账。相反，为了节省费用，它会创建了一笔“分批（batched）”交易。交易可能会包含3个输入（包含3个都对应交易所的“from”支出地址）和12个输出（包含对应不同客户的“to”收款地址，）。在此示例中，假设输出金额加上手续费刚好等于输入，因此没有找零（change）地址。

在下面的图像中，左边为单独交易，右边为分批交易。

由于分批交易包含许多个输出（一对多个客户），因此在数据方面非常大。一笔交易如果体积越大，将其打包入块的成本就越高。在高峰时段，交易所要迅速让交易确认的成本会非常高。（虽然不像12笔单独交易那么贵，但成本仍然很高。）

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

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

安全袋是一个提议中的“ 操作码（OpCode）”——比特币编程语言的一个附加功能。该操作码实质上是让交易所将分批交易“拆分”为两笔交易：“付款”交易和“收款”交易。

其中“付款”交易包含了三个原始输入，对应的是交易所的地址。但它只包含一个特殊输出。这个输出称为“已提交输出（committed output）”，其中包含一个密码哈希值：一个看似随机但相对较短的数字字符串。

这个哈希值实质上是一个唯一的序列号，其链接到两笔交易中的另一个：“收款”交易。安全袋的关键在于，“已提交输出”只能通过这个特定的“付款”交易来使用，并通过哈希值将两者相连。（用技术术语来说，哈希值将提交给除“prevouts”之外的整个“收款”交易，这是一个实现细节。）

可以将“收款”交易视为原始交易的后半部分。它只包含一个输入（对应“付款”交易中的已提交输出）以及所有12个输出。因此，包含所有输出的“收款”交易要比“付款”交易大得多。

在下面的图片中，你可以看到左边是正常的分批交易，而右边是两个独立的交易（“付款”和“收款”）。

当交易所向12个客户发出付款时，会同时广播“付款”和“收款”交易。但这两者之间有一个很大的区别，这就是该方案的核心。体积较小的“付款”交易包含了相对较大的手续费，以确保快速确认。由于该交易很小，从数据角度来说，即使是相对较大的手续费也不会很多。

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

虽然钱还没有到位……但是资金已经被妥善保管好了。

Child Pays for Parent （父债子偿？）

尽管上面概述的基本示例可以确保*这12个交易所的客户最终获得他们的资金，但这可能还不能完全满足他们。

（*如果交易费用一直降不到所需水平，则“收款”交易实际上不会自行确认；这可以通过本文后半部分中介绍的技巧来解决。）

举个例子，这12个交易所客户之一的Alice今天必须向房东交房租。这时，仅仅知道她最终会将从交易所那里收到钱是不够的——不管她有多确定自己会收到钱（房东并不关心）。她实际上需要的是能够花费属于她的输出。

从技术上讲这是可能的。Alice可以拿出她未经确认的输出（12个中的一个），并立即将其用于新的交易中。唯一的问题是：Alice的交易只有在“收款”交易得到确认之后才能被确认。同时，房东又要求付房租的钱今天就要到账。

幸运的是，Alice可以利用一个老的比特币技术来确保“收款”交易和她自己的交易都能得到确认：“Child Pays for Parent”（CPFP）。基本上，如果Alice支付给房东的交易中包含足够高的手续费，则矿工也将被激励把“收款”交易也打包入块——虽然“收款”交易本身的手续费对他们而言吸引力不大。但毕竟，只有两笔交易同时得到确认，他们才能拿到Alice的高额手续费。

也就是说，要加速确认数据量大的“收款”交易的成本将会非常昂贵。这就是为什么交易所第一时间就采用“安全袋”。这时，Alice需要为所有12个客户分批交易的手续费买单，而不是交易所。但这样，同样作为客户的Alice会很不好受。

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

树式支付（Tree Payments）

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

在上面的基本示例中，“付款”交易包含了一个已提交输出，而“收款”交易包含了一个对应的输入和12个正常输出。但其实还可以将这12个输出进一步拆分为更多的“收款”交易。

例如，“付款”交易可以包括两个已提交的输出，对应的是两个不同的“收款”交易，每个“收款”交易都包含六个正常输出。当然，这意味着要进行快速确认的话，“付款”交易的手续费会变高一些，但是Alice要承担的费用将减少一半以上：她只需要承担另外5个其他客户的手续费，而不是11个。

更好的是，交易所可以在初始的“付款”交易和最终的“收款”交易之间创建“中间”交易！这些“中间”交易都包含一个输入和任意个已提交输出，可能还包含正常的输出，从而创建出一种树状结构。这样，即使是服务需要立即作资金周转的客户，交易所也可以合理地降低CPFP成本。赶时间的客户最多只需要为他们相关的中间交易付款，而不用管其余的交易。

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

细节及实现

本文介绍了安全袋（Secure the Bag）的基本实现逻辑。实际上，这个方案可以通过多种方式实现和代替。例如，Alice不必使用CPFP才能向房东付款，而是可以通过闪电网络接收资金，并立即支付给房东。还有其他更复杂的解决方案可以加快“收款”交易的速度。

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

实现安全袋也需要升级比特币协议，不过可以通过向后兼容的软分叉进行。目前方案提出者Rubin已经完成了所需的大部分编码工作——代码和构思仍有待审查。另外，即使提案通过了所有同行的评审，协议升级也可能需要一段时间才能被采用。因此，目前还无法确定“安全袋”什么时候正式上线（如果通过的话）。

『本文转载自网络,版权归原作者所有,如有侵权请联系删除』