譯者：簡單來講，就是對交易進行延遲滿足，或許這個也是比特幣的跨鏈切入口之一

比特幣的網絡擁塞情況千差萬別。在交易高峰期時，成千上萬的交易在等待被打包入塊，從而導致手續費飆升，許多用戶仍不得不等待。與此同時，在交易較少的時候，甚至沒有足夠的交易來填滿整個區塊，最小的手續費就足以快速確認。

當然，對于需要快速完成大量交易的服務來說，高峰時段的網絡擁塞是一個大問題。例如，交易所、礦池或工資單服務有時會同時向數百名用戶付款，而這些用戶可能會迫不及待地想拿到錢，這是人之常情。因此，這些服務需要支付高昂的費用，才能將這些交易優先得到確認。

現在，比特幣核心開發者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已經完成了所需的大部分編碼工作——代碼和構思仍有待審查。另外，即使提案通過了所有同行的評審，協議升級也可能需要一段時間才能被采用。因此，目前還無法確定“安全袋”什么時候正式上線（如果通過的話）。
來源： BTC Media?