七大維度俯瞰，閃電網絡核心開發者萬字點破閃電網絡當前侷限

我在推特上發起了一次調查，發現大家似乎對閃電網絡的侷限性都很感興趣 —— 究竟閃電網絡能做些什麼，又或做不到什麼。今天我就來和大家釐清一下閃電網絡的能力範圍。

原文標題：《乾貨 | 閃電網絡當前的主要侷限》
原文作者：Alex Bosworth
翻譯 & 校對：安仔 Clint、Whisker & 阿劍

Alex Bosworth，閃電網絡基礎設施負責人

一、通道配置問題

從我一開始接觸閃電網絡，我就在思考閃電網絡的目標究竟是什麼；我突然靈光乍現 —— 假如全世界的交易都是閃電交易那會怎麼樣？（當然這不切實際，因爲全世界範圍的交易種類太多了。）我想要以此假設爲切入點，討論如何使得閃電網絡兼容所有的交易。

首先我們要明確閃電網絡的定義 —— 閃電網絡指的是基於餘額鎖定的狀態通道所構建的系統。在系統中你我各自持有一些錢，然後我們使用閃電網絡實現「從我這兒轉錢到你那兒」或「從你那兒轉錢到我這兒」。我們還能使用 HTLCs 擴展以上功能，比如實現「我轉錢給你，然後你再轉錢給某某」。上述行爲的前提是我們具備這些餘額鎖定的狀態通道，這也是閃電網絡的基本功能界限。現在的問題是，這些通道有固定的容量與參與者集合，如果我們臨時需要發送一筆大額交易，而在此之前你從未與收款方有過任何交互，就會面臨通道還未正確設置的問題；你可以自行更改設置，但要求用戶去做這樣的操作就違背了我們設計閃電網絡的初衷。

這可能是使用閃電網絡會遇到的主要問題，不過除此之外，還有一些問題大家可能會有興趣。

一、閃電網絡是嶄新的生態系統、首創的平臺，需要大家學習如何使用它，同時還需要有人進行協議開發、軟件開發、建立路由節點、擔保資金等等。構建閃電網絡生態系統，也是種建設市場的過程，沒有這些人做出貢獻，閃電網絡將一文不值，因此生態系統的建立也是制約閃電網絡的因素之一。

二、Layer-1 是決定閃電網絡能否運作的關鍵因素。即使能夠在鏈下做許多事，我們仍需要保證這些操作都是基於去中心化的 Layer-1，而且鏈下的交易最終能夠上鍊。

就目前情況來看，比特幣網絡是最有可能成爲第二層網絡（閃電網絡）底層支持的 Layer-1。

二、大額交易

從貨幣的角度來看，我們必須確保比特幣是被大衆接受的支付工具，因爲在推薦其他人使用閃電網絡進行支付可能遇到的最大障礙是，該如何說服他們使用這類奇怪的貨幣（比特幣），這對使用者有什麼好處？爲什麼這是件很酷的事？這貌似是我們這種閃電網絡協議開發者無法控制的事，但這對於閃電網絡的發展極爲重要。

我只是要強調，如果你要進行低頻次、高額、偶發的交易，那麼使用閃電網絡會遇到諸多限制，這並不適合你。有很多人問： 「什麼是大額交易？ 5 美元以上算嗎？還是 50、500 美元以上呢？」 —— 這麼問本身就很有問題。

閃電網絡是個市場、是個持續進化的生態系統，你可以將其想象爲互聯網。這個互聯網中還連接者大學的內網和公司的內網，內網裏的使用者彼此關聯，因此網絡帶寬非常大，能夠快速發送信息；然而，一旦使用者登錄互聯網網看視頻或做些其他事，他們就會面臨計算機的「最後一公里」問題：使用者以爲服務商能夠提供高質量視頻，但當他們撥號聯網後，卻發現（因爲網速不夠）看不了高清視頻；又或是使用者想要上傳視頻，卻發現自己上傳網速不夠。

我所謂的「大額交易」問題，跟這個網速問題意思是一樣的。

假如今天有個網絡，彼此之間都在餘額鎖定爲 1000 美元的通道中相互連接，那麼即使我非常富有，想傳輸百萬美元的價值，我還是會受到系統的容量限制。所以即便我有大量的錢，我想在一個鎖定餘額 1000 美元的通道中轉錢給某個人，那麼上限就是 1000 美元，這就是所謂的大額度。

區塊鏈 vs 閃電網絡

你爲什麼要使用區塊鏈？區塊鏈技術很棒，但你得忍受大量冗餘；而狀態通道卻恰好能從冗餘中獲益。如果你正在操作高價值的交易，那麼區塊鏈適合你，因爲區塊鏈能夠避免資產流動過程中可能出現的問題；同時區塊鏈使用起來也相對簡單，如果你需要在一個儘可能安全的地方保存資金，我會說那就用超級冷錢包吧。

區塊鏈網絡將部分責任移轉給整個區塊鏈社區；而閃電網絡將更多責任賦予給使用者，這也意味着使用難度更大，後面我會進一步說明。

託管 vs 閃電網絡

閃電網絡的另一個競爭者是託管式清結算網絡（如， Liquid 或類似交易所），或是其他使用閃電網絡的系統，如 tipping.me 或 我創建的 htlc.me。相比於閃電網絡，託管式工作適合低價值的交易，因爲區塊鏈具有一定的上鍊成本，如果你的交易額度低於這個成本，那就會出現一些問題。因此，區塊鏈在清算小額交易上的困難也制約了閃電網絡。

在發送超大額交易時，閃電網絡也會遇到問題。在區塊鏈發起上千萬的交易對你或許不是事兒，但如果是價值數十億的交易，你就會開始擔心區塊鏈的工作量證明是否靠譜，緊接着你就會想念託管式服務或是其他系統的好；更糟心的是，工作量證明需要耗費很長一段時間，你只能等着。所以閃電網絡能做的事情並非無限多，面對上述這幾種情況，閃電網絡並不是很好的選擇。如果你能夠找到值得信任的託管方、不介意做些妥協、不想把資金的責任攬在身上，那麼託管式服務會比閃電網絡適用。

三、區塊大小限制

我從比較抽象的視角討論閃電網絡的侷限性，如果你主要想了解閃電網絡可擴展性的限制，那我們先來談談區塊大小的限制。究竟一個區塊能夠裝進多少交易，大家對這個數字都非常着迷；我認爲觀察交易如何被裝進區塊是件很有趣的事，所以我自制了一張圖表來展示一筆普通交易的數據構成，因爲開關通道的交易就是一筆普通的交易，所以我們能直接看出一次開關通道需要佔據多少數據量。圖例中表示了一個最小通道，字節都映射爲虛擬字節；因爲使用了隔離見證，所以簽名字節數經過壓縮。按照估算，一筆通道交易大小大約是 112 個虛擬字節數。

這是理論上構造一個通道的最小數據量，我們能將其視爲單位通道大小，推算一個區塊中能容納多少筆通道交易。每個區塊約有一百萬字節的空間，如果我們能夠將通道大小降低至 100 字節左右，理應能在區塊中放入大量的通道。但實際上並非如此，要獲得精確的單位通道大小，還需要經過更多複雜的考慮。

節約虛擬字節的技巧

有什麼方法能夠使通道開關交易大小縮減爲理論上的最小值？如果所有交易只有一個輸出，便能節省很多空間。但是當我們關閉一個通道時，可能會有多個輸出，因爲通道中至少有兩方在進行資金轉移。這時候你可以站出來呼籲，「爲了降低上鍊的數據大小，我們在關閉通道前進行一下重整吧」；所以我們會以某種方式推出其中一個輸出，使得區塊鏈只需要處理一個交易輸出。這麼做能節省區塊空間，同時節省費用。

另一種釋放鏈上空間的做法是， 「開啓一個通道的同時，關閉另一個通道」。換句話說，因爲某些交易輸出能作爲其他交易的輸入，所以我們能將通道合併爲一。這是個非常有用的技巧。

另一種我們當前尚不支持，但是短期內會看到進展的有用技術是多簽名形式轉化，也就是把多重簽名壓縮爲單個簽名的技術。這一技術極爲強大，幾乎不存在什麼重大缺陷。通過簽名聚合，我們能夠將大量的簽名合而爲一。如果能用 Schnorr 和 Musig 進行簽名整合當然很好，不過以橢圓曲線數字簽名（ECDSA）實現也行。

還有一件事需要考慮，很多時候人們會估算上鍊的成本，並傾向不配合關閉通道。比如存在這種情況 —— 「我們要將通道輸出廣播上鍊，但是對方掉線了，該怎麼辦？」

在示例中，如果有一方選擇不配合關閉通道，這並不需要通過什麼複雜的腳本來解決，因爲我們可以直接將不配合關閉通道的操作視爲交易失敗條件之一。我們應該嘗試以時間鎖或更高昂的費用，通過經濟手段激勵人們彼此配合關閉通道，比如，如果不合作關閉通道，就得付出更多的費用。

另一個我們已經實現的節省虛擬字節的方案是關於粉塵交易輸出的（比如在閃電網絡中，可能出現只值半美分的交易輸出），因爲在上鍊環節，這種極小額的交易輸出會被區塊鏈拒絕，或在對等傳輸階段視爲垃圾交易。作爲解決方案，軟件會將這些極小的輸出放進礦工費中，因此，當我們必須以不配合的方式關閉通道時，能夠稍微提高交易確認速度。

增加通道成員，減少虛擬字節

改善閃電網絡的又一利器則是創建多方，而非僅僅兩方參與的通道。當然這樣的設計並非萬全之策，而且這種機制的複雜性限制了它的落地應用。目前我們最多隻能在一個通道中加入兩個參與者，而在一個通道中加入更多人其實正是拓展虛擬字節利用率的絕佳手段。

單個通道中加入多個參與者的約束條件在於，究竟輸入會被轉換爲多少個輸出？通道內的交易最終還是要落到區塊鏈上的，即使某一時刻不打算上鍊打包交易，我們也要具備交易隨時上鍊的能力。

而現在面臨的的限制是每個人都想要拿回屬於自己的那一份交易輸出。比如說現在到了關閉通道的時候，我想收回屬於自己的錢，此時每一個輸出都要花費大約 30 個虛擬字節。其實這時候你還不一定需要耗費這 30 個虛擬字節，但當你在在通道中遇到分歧，沒法最終整合到一個輸出的情境時，就必須多消耗這 30 個虛擬字節。

必須提醒一點的是，這些多方參與的通道，在建立時只需要一個人進行注資，即僅需要一個人來建立輸入併發起交易。我實際上可以在向通道注資之後廣而告之，「來十個人加入我剛剛建立的通道吧，這個通道的注資輸入是我一個人的，大家接下來就把我的輸入折騰成大家的輸出，當然這些輸出不會即刻反映到區塊鏈上，除非我們沒法繼續重整這些輸出，只能不情願地關閉通道，將交易廣播上鍊。」

多方參與的通道，人數可以達到相當高。基於我之前提到的簽名整合技術 —— 將數百個簽名整合到一個簽名上 —— 理論上我們能在一個通道內加入數以千計的參與者。在設置輸入需要留意：你其實也在設置大家的集體公鑰，而集體公鑰是由所有人的公鑰進行哈希處理整合而成，所以並不需要多大的存儲佔位空間，就是固定大小的一段。

如果上述想法能落地實現，就意味着我們能夠在一個區塊中添加成百上千的通道。不負責任第暢想一下，也許能有數以千計的參與者加入到通道中。即使從現實出發，達到數十成百的參與者也不成問題。按這樣計算，在一週之內我們能處理達到百萬量級人次的交易。如此看來，以增加通道參與方的數量的方式來攫取通道的處理潛力具有相當大的探索空間，並且這種努力的方向並不會改變區塊鏈的屬性。

四、責任

把話題拉回系統設計，我想談談閃電網絡的延展性設計以及我們如何實現延展。在系統中我們面臨着這些問題，同時也是責任。系統中的參與者必須要回答以下問題：誰的錢會歸誰？誰在其中起操控作用？這些操作是在通道中發生的嗎？通道是怎樣建立的？誰在驗證這些操作？誰來保證每個人都遵守了規則？同時如何確保每個人都獲取到了正確的數據？以上都是區塊鏈和閃電網絡在延展性上中所遇到的高級問題。

責任分攤

閃電網絡的設計路線是分攤責任。系統中每一個人都需要儘可能控制好自己的那一部分責任，這樣以來，就能在不給整個系統過多負擔的責任下使盡可能多的人蔘與進來。閃電網絡中將要使用的一條原則是：「你必須保管好自己資金的數據庫」。

除你之外，沒有人有義務告訴你這筆交易收了多少錢，你必須追蹤自己交易的元數據，即：誰發送了交易，你又把交易發給了誰，這些將會是你自己的責任，而不是大家共同分擔的責任。

當你在做某些全局性的操作而要給其他人證明的時候，你只需向他們展示最基本的證據證明自己的操作是合法的。如此一來，加入的新用戶不會給系統帶來負擔，而其他的方式會破壞網絡增長的延展性。我們同樣設置了機制來保證用戶僅僅需要覈驗區塊、檢查與自己發生交互的其他參與者的交易簽名和操作。用戶只需要和固定數量的一小撮其他參與者發生交互，而不需要每來一個新人就費勁地核驗一番。這種思想同樣體現在了閃電網絡的數據共享上。我們將會把僅把那些和你直接相關——即你需要關注的——可能是交易中一部分的數據分發給你。限定用戶交互的其他參與者數量，能保證拓展網絡的同時不至於增大添加新用戶的邊際成本。

責任代理

這給用戶加入閃電網絡帶來了挑戰。在區塊鏈中，系統其實已經替你完成了許多工作，用戶無需對自己資金的數據庫負責，而是由區塊鏈系統自動完成。你只需要拿好自己的助記詞，下載好區塊鏈，它會把所有的區塊掃描一遍來檢查你的資金存放位置。我們在這個方向上做了更多的工作。雖然有很多提案表示用戶應該負更多的責任，來讓 Layer-1 得以擴展，但至少目前我們並不是這麼做的。目前，只要你沒忘記助記詞，別的都好說。在區塊鏈上，延展之所以成爲一個難題，是因爲系統中新用戶的加入增加了需要覈驗的人數。舉例來說，如果網絡中增加了一千個新用戶，那每一個老用戶都要覈驗這一千個新人，這非常不利於延展。從用戶之間的數據共享角度看，用戶越多意味着數據越多，所以隨着網絡的拓展、資源開銷也急劇增大。

在區塊鏈上靠別人替你操作數據着實舒心，而在閃電網絡上要靠自己管理這一切就沒那麼友好了。如果用戶丟失了自己的數據庫會有什麼後果呢？由於我們取消了數據庫共擔的責任，現在數據庫維護完全是用戶自身的工作了。如果你把數據庫弄丟了，那可要倒大黴了。

處理這個問題的一種途徑是「大家來採用責任代理」。即不把責任完全壓在用戶的肩上，而是有一些公攤的責任，但是需要用戶來決定自己想承擔多少公攤責任。我們目前把這種機制叫做數據丟失保護協議，lnd 對這一特性正有所需求。

你的夥伴節點會幫助你保存一小組數據，在你想要關閉通道但丟失了部分數據的時候，爲你提供所需要的數據來完成關閉操作。我們剛剛在 0.6 版本中加入這個功能來實現靜態通道備份系統。這是一組你從別處複製過來的數據，你可以把他複製到 P2P 服務裏，也能如你所願直接放到 Google Drive 上。它以一個加密的、很小的文件形式來呈現。我們目前正在致力於研發瞭望塔工程，當你不想要一直監視着通道，或者相對自己的通道承擔所有的責任時，可以把這些工作外包給瞭望塔完成。

在區塊鏈之類的系統中，如果有人想要搞雙花或者別的破壞，整個社交網絡會聯合起來粉碎他們的陰謀。正義之士會譴責：「你不能這麼做，這沒任何好處」。或者通過別的方式來無效化這些攻擊行爲。將這種行爲類比到閃電網絡中，你可以講：「我要選這些人當我的觀察員，雖然我也可以自己完全攬下這些工作，但那樣我就只能一直在網絡上掛着了」。同樣由於區塊鏈是一個共享所有數據的分佈式賬本，它會爲你保管相關的數據。而在閃電網絡中，如果你不在線，那就有可能接收不到和自己有關的數據。所以我們可以把責任代理出去，告訴所有人：「這個節點可以作爲我的信箱。」充當信箱的節點會延遲 HTLC （哈希時間鎖合約）最後一步的操作，然後向你發送郵件，或者你可以每天登陸一次閃電網絡，檢查郵箱是否收到郵件。接着由你來完成 HTLC 最後一步的操作。上述機制設計的關鍵在於，你雖然需要他人充當你的信箱，但他們無法對你的資產做任何處置。我們在責任委派上會設計一種溫和的解決方案。

作者 : Alex Bosworth

翻譯 & 校對 :IAN LIU, 安仔 Clint & 阿劍

五、路由限制

閃電網絡中另一個常被提及的困境是：我們如何設計路由？閃電網絡中的路由跳轉是十分困難的，它的理論依據建立在 「六度人脈」現象之上（譯者注：可通俗地闡述爲：「你和任何一個陌生人之間所間隔的人不會超過六個，也就是說，最多通過六個人你就能夠認識任何一個陌生人。」）。在如此龐大、數以百萬計的用戶之中選擇路由，從當前百萬用戶中的這一個跳轉到另一個百萬中的下一個，這是十分困難的問題。

不過，人們之間是有聯繫的，我認識你，而你認識他，這麼一想，理論上我不難通過這一個個的中間人跳轉到接收方用戶。而實際操作中的問題在於，我們無法得知究竟誰在線，誰能幫我們找到目的用戶。僅僅知悉用戶之間的關係是遠遠不夠的，還必須知道誰能對路由請求作出響應。用戶同樣不知道別人的通道內有多少資金，所以還要知道哪些路徑能便於我們重整好自己的資金，使得無論我們向誰發起交易都可以順利進行。想想在一部手機上要搞清楚數十億人的關係、那麼多的數據要及時更新，這簡直是異想天開。讓用戶對整個圖有完整的認識不切實際，我們想要做的是讓用戶只知道網絡中一部分的關係（就能讓整個網絡運轉起來）。

死衚衕

路由還有另一個問題，大問題。如果有個節點沒把你的 HTLC 轉發出去，怎麼辦？如果他們坐視不理，或者取消掉了後續轉發、回到了鏈上，怎麼辦？閃電網絡賴以運轉的智能合約就建立在這些區塊時間上。區塊時間可以很久，理論上長達數日。Lnd 允許你設置自己可接受的區塊時間，但要讓路由節點也接受這個時間纔行。弔詭之處還在於，因爲閃電網絡是洋蔥路由網絡，你無法得知是誰在爲你轉發路由。在你從這一點發送交易之後，整條線路上由別人處理你的交易。你能感受到操作的延時，但無法探查究竟是什麼緣故，或者要等多久。雖然這不會影響到資金安全，但你的錢在這個過程中是被鎖定的，叫天不靈，叫地不應的用戶體驗很讓人鬧心。想完成支付，卻不能立即完成，這就是閃電面臨的路由問題。

一個可信賴的路由網絡

旨在解決這些問題的一種方案就是將節點分爲各個有着不同責任的角色。每個節點都可以擔當自己想要做的任何角色，所以你可以認爲每個節點都是一樣的，只不過某些節點希望和其他節點有所區分，扮演不同的角色。一個簡單的例子就是，移動端節點的用戶並不希望自己的手機時刻連接着互聯網，畢竟有着數百萬的節點已經在進行這樣的工作了。他只希望成爲一個消費節點。如果可以的話，他可以成爲一個路由節點，但這並不是他所希望的。

未來我們會看到節點的專業分化。我們將會有一組特定的節點來進行轉賬並賺取手續費。我們會將網絡分成不同類型的節點。如果我們能夠建立一個這樣的網絡，在其中可以根據節點的行爲識別出哪些節點是路由節點，那就可以讓用戶自主選擇路由節點 … 之所以我會選擇你來發送我的流量，是因爲你看起來經常在線，成功率和速度都不錯。如果我們能夠構建這樣的網絡，必然會有在網絡邊緣的人，那些移動錢包或是那些對於路由不感興趣或是不擅長的人就會被分配到網絡邊緣。而在網絡中心將是那些擅長路由、長期在線並且能力強的節點。之後我們就可以更好地瞭解如何在網絡上從 A 點走到 B 點。它像是模擬互聯網一樣，在你的筆記本電腦上運行一個 web 服務器，但是你不是必須這樣做的。你可以將它運行在某地的一臺服務器上。如何構建它都取決於你，但如果你想要在互聯網上進行路由，則可能需要選擇一臺服務器。

這也解決了我們之前說到的資本流動性問題。如果說路由節點等價於寬帶路由器，路由節點之間有大容量的通道，那麼你就不再需要考慮到達目的地的流動性問題。你可以依賴路由節點很好地連接彼此。

唯一的問題就是你能否到達路由節點，這話反過來說也是一樣的，即接收方是否可以從路由節點收到你的交易。這使得問題變得愈加簡單，因爲你不必擔心（在傳遞路徑中的）六個 hop 是否具有適當的流動性，你只需要關注的是傳遞過程中是否第一個 hop 是你，最後一個 hop 是接受者就可以了。爲了達到這個效果，我們需要建立一個市場。我們需要的是獎勵那些完成工作的路由節點，致使路由節點運行順暢，路由節點的運行代價不高，所以它們只需要收取有限的手續費。這是一種市場形成的過程，也是一種軟件完善的過程。

公共參考點

一旦我們擁有了這樣的網絡，我們就可以使用良好的路由節點，同時也解決了路由圖的計算問題。我們原本的想法是：我是十億人中的一員，所以我需要通過這樣的十億人的網絡才能從我的節點到達其他人的節點，這怎麼可能做得到呢，我甚至連路由圖都沒有。

但是現在，比如如果要發起一個收款請求，那麼你可以把與你連接良好的參考點節點都記錄下來（併發送給我）。你可以把所有良好的路由節點都視爲參考點。當我選擇進行付款時，我可以看到（所有的）參考點，因爲參考點的數量是有限的，同時它們之間也很好地連接在一起。

雖然我不能瞭解整個路由圖，但是當你發送付款請求給我時，其中可以包含到達你的節點的最後一部分路徑。這使得路由變的更加簡單。我們甚至可以將路由時間段外包，甚至僅外包有關的計算部分。

一些人最近在郵件上談及如何保證隱私性。如果你沒有這方面的需求，你只需要支付給你能找到的人，讓他們來跟網絡中的數十億人保持同步。他們會想盡辦法來找出最經濟的模式。你可以在不信任他們的前提下外包給他們，因爲你可以 …（譯者注：原文如此）。同時，我也認爲還存在着外包的權衡，由於整個網絡的權衡，你可能無法獲得完美的路徑。可能會存在手續費更低，隱私性更好的方案。

目前爲止，路由圖算法只能集中在爲你提供當前最低費用，並隨着時間不斷嘗試更低的費用。而在未來，由於存在有限性，我們認識到是無法獲得完美的路徑的，所以我們只需要得到一個可接受的路徑即可。

六、資金限制

另一個我之前談及的在閃電網絡上的巨大限制就是存在着資金限制。你擁有一些小的（轉賬）通道，小的（UTXO）輸出。你發送了 100 聰但這筆交易卻無法上鍊（因爲金額太小）。如果你有更多的錢，比如 5 美元，無論當前手續費或是鏈的使用條件如何，你都可以將這筆交易上鍊。大額的交易也會遇到流動性問題。這就是閃電網絡的基本限制。

多支付路徑

目前存在一種解決方案，雖然沒有完全解決，但是這樣的通過多路徑到達目的地的想法也確實對後續發展很有幫助。我們有多種實現的方法。目前我們可以立即採取一種已經在真實網絡中測試過並且實現不太難的方案，這就是 Base AMP。舉個例子： 「我想要得到 100 美元，所以在收到 100 美元等值的 HTLC （哈希時間鎖定合約）之前我就一直等着，你將通過不同的路徑來發送總價值爲 100 美元的多個 HTLC，在收到所有 HTLC 之前，我只接收，但不會公開那個 pre-image （即用於構建哈希鎖的數據）。一旦我拿到了 100 美元，我就公開 pre-image ，並取出所有 HTLC 裏面的錢」。這是一種技術含量不高但是安全的 AMP 方案，雖然當前客戶端沒有很好地支持這一點，但確實是一種值得一試的方案。

另一種發送更多資金，規避單個通道的最大值限制的處理方案則爲，如果我們在單個轉賬方向上擁有多個通道，採取同樣的方案，你只需要在兩個不同的節點間等待多個 HTLC 。甚至不需要讓發送方和接收方知道這一點，只需在路由路徑中如此設置便可。

未來我們可以採取這樣一種方案，我們拿到 pre-image 並將其分解成爲一堆不同的加密後的信息，這樣即使在 Base AMP 中，接受者也會受到經濟激勵一直等待，無法獲取信息。通過使用 Schnorr 簽名，使用更加高級的結構，即使他們想要得到這樣的信息也不能實現。

多系統支持

我們依託閃電網絡能做的另一件事就是接受它的這些侷限性，並提出各種小技巧來處理一些邊緣情況。由於體積小，我們可以讓一些小額的（UTXO）輸出成爲交易費。同時我們也可以做一些瘋狂的事情，比如概率支付，「我們有 1% 的機率獲得 100 美元」 之類的。我們可以使用這條鏈或者那條鏈。我們可以使用 Liquid 側鏈。如果我們爲了絕對地最小化鏈上通道的大小而關閉通道和移除流量，這可能會派上用場。我們可以使用不同的方法，使用其他不同的鏈，通過 submarine swaps （一種主鏈與閃電網絡資產轉移方案）來將其他的輸出轉移。我們也可以迴歸到鏈。我們可以說，「讓我們將主鏈發送的資產和閃電網絡發送的資產整合到同一個錢包中，這樣的話，如果發送金額過大而導致失敗，我們可以接受，同時切換到主鏈上協同完成轉賬。」現在人們也在嘗試着一種叫做 turbo 的模式，在特定的情形中，它能實現零確認通道。這意味着你可以同時獲得主鏈和閃電網絡的優點，即你可以留在閃電網絡系統中但是使用主鏈轉移任意高價值的資產。另一種我覺得很酷的方式，我不知道是否有人正在研究這個問題。就是在小規模交易中，我們可以使用客戶端簽名來處理節點間的一些小 commitment 。我們可以使用電子現金以便你可以隱祕交易一些在主鏈上沒有意義的微小的 commitment。最後一點，我們可以做的另一件事就是提高資產的限制值，由此來增加資本市場的複雜度。這也是現在人們所努力的另一個方向，比如 Bitrefill 着力於 turbo 模式但是同時也着手於 Thor 這個項目，這個項目就是允許你購買 inbound 流動資產（即接收其他節點數據），這和我們 Lightning 實驗室的 Lightning Loop 項目不謀而合。當我們擁有更多的工具，我們就會吸引到更成熟的買家和賣家，就可以更加增強你規避資產限制的能力。

七、1.0 版本協議限制

我在這個演講中加入了許多其他的東西。我想談的是， 1.0 的協議事實上有一些惱人的限制。我希望在這裏強調一遍。考慮到閃電網絡的重要性，雖然它不是一個一成不變的協議，也需要我們去適應和發展。這是一件好事。

我認爲在 1.0 版本的協議中首先要被修復的問題就是，當你強制關閉一個通道時，返回的強制關閉的（UTXO）輸出使用的是隨機密鑰。如果你只有你的種子，你無法從主鏈中去掃描所有區塊以找到你的資產，因爲這些是使用隨機密鑰的而你不知道隨機數是多少。這就是 1.0 版本中的一個問題。這增加了你自己所需要備份好的材料數。你需要時時保留着自己的隨機數。

當然，還有其他一些問題。每當你在區塊鏈上關閉一個通道時，相應的資金就會被鎖定到一筆 CSV 輸出中（即 CheckSequenceVerify
文件），這也就意味着會鎖定一定的時間，只有在一定的區塊被挖出後才能解鎖。這就衍生出另一個問題，你無法在一筆 CPFP （Child-pays-for-parent） 的交易中對父交易額外收費（bump the fees），因爲你無法在幾個區塊確認前花掉它。 CPFP 要求你把父交易和子交易放進同一個區塊中，以便將利益綁定給同一個礦工。我們所已知的另一個問題則爲，通道的容量是固定的，且我們對通道的容量會有一個較低的限制，比如 0.16。這就產生了很多問題，尤其是讓交易所支持閃電網絡。現在非常難實現。另一個關於支出的問題在於，如果你在資金暴增期間有一些手續費較低的交易，你將會很難和其他節點協商提高手續費。這也是閃電網絡現在面臨的侷限性，因爲協議還不支持，你無法發送給別人，別人也無法接受。

升級到 1.1 版本的協議

而在 1.1 版本中，如果可以順利完成，我們會添加各種新功能來解決上述的所有問題。我們會將遠程地址設置爲靜態的，這樣如果經歷了強制關閉通道，你也可以通過掃描整條主鏈來獲得你想要的信息。你也不必保留那串隨機數了。在 CSV 約束的交易中，我們會增加別的一些引發條件。我有些超時了，就不繼續延伸，進入問答環節吧。

八、問答

Q – AMP 是否存在當前系統一樣的問題，即一個節點可能會扣住 HTLC 並且會鎖定流動性？這要怎麼處理？

A：當然，首先，我認爲你必須要考慮整個路由節點網絡。你並不是通過完全隨機的節點進行發送的。你的發送是通過專門的節點網絡進行的。事實上，這些被選出的節點是被你的大額手續費所激勵的。你仍然有這樣一個問題，即你不確定哪些節點是作惡的。有另外一種方法可以解決這個問題。一旦我們有了這些推送交易，或者我們和接收方有更多的交互，我們就可以通過一些測試查看是否有效來預先確認路由路徑。在這種情況下，我們使用的並不是真正的錢，我們使用的是他們所不知道的一些虛假的哈希。我們可以說「這個問題已經是過去式了」。我們可以再次發送。准此，我們可以讓這種情況變得越來越少。

Q – 如何解決網絡中廣泛的通道平衡問題？

A：我確實認爲我們應該反思把資本當成商品的觀念。流動性是一種產品。我看到許多人談到 「你們能否爲我注入一些流動資產？」。我認爲相對應的成熟方式是「你想要 inbound 流動資產？請先進入 inbound 流動市場去尋找是否有你想要的 inbound 流動資產。」一旦我們有了更成熟的方案，我們就可以針對你的特定的流動性問題提出更簡單的方法。

Q – 是否可以在通道打開之後更改願意轉發的 HTLC 的價值下限？

A：是的，我認爲這個大小是可調整的。你可以說這是通道策略的一部分。當然，在技術上是可能的。你可以接收到一個 HTLC 然後說「這太小了，我拒絕接收。」

Q – 我們是否會在 1.1 版本中增大通道的大小？

A：是的，事實上它是無限的。通道的容量是不受限制的。但是我們仍然會遇到這樣一個問題，我們可能需要一些默認的安全限制，因此我們可以討論一下比較合理的數值。第二點，即使路徑中的一個節點具有巨大的容量，也不是意味着路徑中所有節點都擁有這麼大的容量，因此，一種更好的方式就是作爲一種生態系統慢慢增長。

Q – 我想要將我的 Ind 節點移到 .onion 網絡中，以隱藏我的 IP , 但是我希望我還是可以通過 Ind REST API 來訪問我的電子商務商店，你覺得我應該怎麼做？是使用 VPN 以取代 Tor 嗎？

A：不。 Tor 只適用於閃電網絡節點本身。我在基於 Tor 的 Yalls.org 上用自己的節點執行你這樣的操作。我建議大家都基於 Tor 來搭建自己的節點，這很酷。它依舊會保持正常的網絡開放，所以你可以正常獲取自己的 IP 並使用。

Q – 你覺得在 1.1 這個版本中哪些首要用例或是服務會開放？

A：確切的我不是很清楚，這些仍在制定中。推送交易是我最期待的一個，因爲它允許在網絡上完全交互。你可以使用僅存在於閃電網絡上的 API，在其他地方沒有。你使用的不是一個 HTTP REST API ，而是一個閃電網絡 API 。這對我來說是最酷的一件事。

Q – 對於那些試圖更好的瞭解閃電網絡的開發人員，你有什麼推薦的嗎？

A：我非常喜歡 BOLT RFC ，這也是我初探閃電網絡的地方。我剛剛瀏覽了所有不同的 RFC。他們有所變化，但是你依舊可以看到一些主鏈交易或是其他事物。 Lightning Labs 有一套 API 開發系統，在那上面我建了自己的內服務庫，可以能讓事情變得簡單，運行良好。這也是我在建立 Y’alls 和 HTLC.me 時所用的。

來源鏈接：diyhpl.us