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