電子發(fā)燒友App
譯者：簡單來講，就是對交易進行延遲滿足，或許這個也是比特幣的跨鏈切入口之一
比特幣的網(wǎng)絡(luò)擁塞情況千差萬別。在交易高峰期時，成千上萬的交易在等待被打包入塊，從而導(dǎo)致手續(xù)費飆升，許多用戶仍不得不等待。與此同時，在交易較少的時候，甚至沒有足夠的交易來填滿整個區(qū)塊，最小的手續(xù)費就足以快速確認。
當然，對于需要快速完成大量交易的服務(wù)來說，高峰時段的網(wǎng)絡(luò)擁塞是一個大問題。例如，交易所、礦池或工資單服務(wù)有時會同時向數(shù)百名用戶付款，而這些用戶可能會迫不及待地想拿到錢，這是人之常情。因此，這些服務(wù)需要支付高昂的費用，才能將這些交易優(yōu)先得到確認。
現(xiàn)在，比特幣核心開發(fā)者Jeremy Rubin認為，他已經(jīng)找到了如何可靠地緩解網(wǎng)絡(luò)擁塞的方法，可以提高高峰時段比特幣的吞吐量。
他的解決方案被稱為 OP_SECURETHEBAG。
安全袋技術(shù)（Securing the Bag）
要了解OP_SECURETHEBAG（下面簡稱為“安全袋”），讓我們以一個實際的示例為例，從基礎(chǔ)入手。在此示例中，有12個客戶都要求交易所在手續(xù)費較高的時候發(fā)出提現(xiàn)請求。（實際情況中，這個數(shù)字可能會是1200個，這里以12個客戶為例是為了更容易解釋概念。）
即使沒有安全袋，交易所也不會那么傻的創(chuàng)建12筆單獨的交易來分別向每個客戶轉(zhuǎn)賬。相反，為了節(jié)省費用，它會創(chuàng)建了一筆“分批（batched）”交易。交易可能會包含3個輸入（包含3個都對應(yīng)交易所的“from”支出地址）和12個輸出（包含對應(yīng)不同客戶的“to”收款地址，）。在此示例中，假設(shè)輸出金額加上手續(xù)費剛好等于輸入，因此沒有找零（change）地址。
在下面的圖像中，左邊為單獨交易，右邊為分批交易。
由于分批交易包含許多個輸出（一對多個客戶），因此在數(shù)據(jù)方面非常大。一筆交易如果體積越大，將其打包入塊的成本就越高。在高峰時段，交易所要迅速讓交易確認的成本會非常高。（雖然不像12筆單獨交易那么貴，但成本仍然很高。）
交易所也有可能會用較低的手續(xù)費來節(jié)省成本，在這種情況下，需要一段時間來確認交易。但是在交易確認之前，客戶不確定他們是否真的會收到這筆錢，需要一直等待：這筆錢可能會被雙花，直到交易被寫入?yún)^(qū)塊。這會讓客戶很不高興，交易所也不想這樣。（在某些情況下，甚至可能不允許讓客戶等待：例如，根據(jù)合同，工資發(fā)放時有義務(wù)在特定的某一天確認交易。）
安全袋的作用就體現(xiàn)在這里。
安全袋是一個提議中的“ 操作碼（OpCode）”——比特幣編程語言的一個附加功能。該操作碼實質(zhì)上是讓交易所將分批交易“拆分”為兩筆交易：“付款”交易和“收款”交易。
其中“付款”交易包含了三個原始輸入，對應(yīng)的是交易所的地址。但它只包含一個特殊輸出。這個輸出稱為“已提交輸出（committed output）”，其中包含一個密碼哈希值：一個看似隨機但相對較短的數(shù)字字符串。
這個哈希值實質(zhì)上是一個唯一的序列號，其鏈接到兩筆交易中的另一個：“收款”交易。安全袋的關(guān)鍵在于，“已提交輸出”只能通過這個特定的“付款”交易來使用，并通過哈希值將兩者相連。（用技術(shù)術(shù)語來說，哈希值將提交給除“prevouts”之外的整個“收款”交易，這是一個實現(xiàn)細節(jié)。）
可以將“收款”交易視為原始交易的后半部分。它只包含一個輸入（對應(yīng)“付款”交易中的已提交輸出）以及所有12個輸出。因此，包含所有輸出的“收款”交易要比“付款”交易大得多。
在下面的圖片中，你可以看到左邊是正常的分批交易，而右邊是兩個獨立的交易（“付款”和“收款”）。
當交易所向12個客戶發(fā)出付款時，會同時廣播“付款”和“收款”交易。但這兩者之間有一個很大的區(qū)別，這就是該方案的核心。體積較小的“付款”交易包含了相對較大的手續(xù)費，以確?？焖俅_認。由于該交易很小，從數(shù)據(jù)角度來說，即使是相對較大的手續(xù)費也不會很多。
相比之下，較大的“收款”交易包含相對較低的費用，這意味著可能需要一段時間才能確認。但是在這里，等待低價交易確認對客戶來說不是大問題了，因為一旦“付款”交易被確認，就可以確保這筆錢保證對應(yīng)唯一的“收款”交易。資金會被錨定在區(qū)塊鏈中，只能由這幾個交易所客戶接收。
雖然錢還沒有到位……但是資金已經(jīng)被妥善保管好了。
Child Pays for Parent （父債子償？）
盡管上面概述的基本示例可以確保*這12個交易所的客戶最終獲得他們的資金，但這可能還不能完全滿足他們。
（*如果交易費用一直降不到所需水平，則“收款”交易實際上不會自行確認；這可以通過本文后半部分中介紹的技巧來解決。）
舉個例子，這12個交易所客戶之一的Alice今天必須向房東交房租。這時，僅僅知道她最終會將從交易所那里收到錢是不夠的——不管她有多確定自己會收到錢（房東并不關(guān)心）。她實際上需要的是能夠花費屬于她的輸出。
從技術(shù)上講這是可能的。Alice可以拿出她未經(jīng)確認的輸出（12個中的一個），并立即將其用于新的交易中。唯一的問題是：Alice的交易只有在“收款”交易得到確認之后才能被確認。同時，房東又要求付房租的錢今天就要到賬。
幸運的是，Alice可以利用一個老的比特幣技術(shù)來確?！笆湛睢苯灰缀退约旱慕灰锥寄艿玫酱_認：“Child Pays for Parent”（CPFP）?；旧?，如果Alice支付給房東的交易中包含足夠高的手續(xù)費，則礦工也將被激勵把“收款”交易也打包入塊——雖然“收款”交易本身的手續(xù)費對他們而言吸引力不大。但畢竟，只有兩筆交易同時得到確認，他們才能拿到Alice的高額手續(xù)費。
也就是說，要加速確認數(shù)據(jù)量大的“收款”交易的成本將會非常昂貴。這就是為什么交易所第一時間就采用“安全袋”。這時，Alice需要為所有12個客戶分批交易的手續(xù)費買單，而不是交易所。但這樣，同樣作為客戶的Alice會很不好受。
所幸，安全袋提供了更好的解決方案。
樹式支付（Tree Payments）
為了解決Alice的問題，交易所可以進一步使用“安全袋”的特殊手段。
在上面的基本示例中，“付款”交易包含了一個已提交輸出，而“收款”交易包含了一個對應(yīng)的輸入和12個正常輸出。但其實還可以將這12個輸出進一步拆分為更多的“收款”交易。
例如，“付款”交易可以包括兩個已提交的輸出，對應(yīng)的是兩個不同的“收款”交易，每個“收款”交易都包含六個正常輸出。當然，這意味著要進行快速確認的話，“付款”交易的手續(xù)費會變高一些，但是Alice要承擔的費用將減少一半以上：她只需要承擔另外5個其他客戶的手續(xù)費，而不是11個。
更好的是，交易所可以在初始的“付款”交易和最終的“收款”交易之間創(chuàng)建“中間”交易！這些“中間”交易都包含一個輸入和任意個已提交輸出，可能還包含正常的輸出，從而創(chuàng)建出一種樹狀結(jié)構(gòu)。這樣，即使是服務(wù)需要立即作資金周轉(zhuǎn)的客戶，交易所也可以合理地降低CPFP成本。趕時間的客戶最多只需要為他們相關(guān)的中間交易付款，而不用管其余的交易。
如下圖所示，交易所可以根據(jù)自己的需求選擇最適合的方式來創(chuàng)建這種樹狀交易結(jié)構(gòu)。（中間步驟越多，通常需要在區(qū)塊鏈上確認的總交易數(shù)據(jù)也會越多，但每個用戶的成本會越低。“鏈式”付款類似于樹式支付，但更依賴于交易的時間順序。）
細節(jié)及實現(xiàn)
本文介紹了安全袋（Secure the Bag）的基本實現(xiàn)邏輯。實際上，這個方案可以通過多種方式實現(xiàn)和代替。例如，Alice不必使用CPFP才能向房東付款，而是可以通過閃電網(wǎng)絡(luò)接收資金，并立即支付給房東。還有其他更復(fù)雜的解決方案可以加快“收款”交易的速度。
此外，嚴格來說，方案中的“安全袋操作碼”不是實現(xiàn)兩階段支付解決方案的唯一方法。即使使用當前的比特幣協(xié)議，也可以實現(xiàn)類似的目的——但是要求所有接收者進行協(xié)調(diào)與合作，這在交易所及其客戶的例子中很難實現(xiàn)，而且隨著更多用戶加入，這種情況將變得更加困難。其他解決方案（例如 covenants 契約）需要升級比特幣協(xié)議才能實現(xiàn)。
實現(xiàn)安全袋也需要升級比特幣協(xié)議，不過可以通過向后兼容的軟分叉進行。目前方案提出者Rubin已經(jīng)完成了所需的大部分編碼工作——代碼和構(gòu)思仍有待審查。另外，即使提案通過了所有同行的評審，協(xié)議升級也可能需要一段時間才能被采用。因此，目前還無法確定“安全袋”什么時候正式上線（如果通過的話）。
來源： BTC Media?
工商網(wǎng)監(jiān)
評論