作者：roasbeef
來源：https://delvingbitcoin.org/t/ln-summit-2024-notes-summary-commentary/1198
大約 3 周以前，超過 30 位閃電網絡的開發者和研究者齊聚日本東京，在三天中討論了許多跟閃電網絡協議（以及相關的比特幣 P2P 協議和共識協議）當前的狀態和未來的發展有關的問題。
此前，最後一次這樣的會議發生在 2022 年 6 月的美國加州奧克蘭：LN Summit 2022 Notes & Summary/Commentary 。一份粗糙的會議筆記即總結可見此處：LN Summit Oakland 2022 - Google Docs 。
我對本次閃電網絡開發者會議的速記可見此處：Lightning Summit Tokyo - 2024 - Google Docs 。而我們商定的每日議題時間表可在此處找到：lightning summit.md · GitHub 。
值得一提的是，有許多的小組討論沒有出現在我的筆記中（雖然我已經盡力了），也沒有反映在上述日程表中。
說了這麼多，下面才是我對主要的討論話題以及結論的總結嘗試（還有一些評論）。如果與會者在我的總結中發現了不準確、不完整之處，關於這三天期間發生的討論以及決定，請回復並填上這個空白。
交易包轉發和 V3 承諾交易怎麼樣了？
這是我們討論的第一個重大話題，緊隨 Bitcoin Core 28.0 的最新候選版本發佈的步伐（在本文撰寫之時，28.0 版本已經發布）。
手續費估計和基本承諾
在跳到迄今為止最新、最偉大的新提議的承諾交易設計之前，我要先簡述一下今天的承諾交易設計是如何工作的，以及它的短板在哪裡。
（如果你已經知道當前的閃電通道中承諾交易是怎麼工作的，你可以跳過這一節）
閃電網絡的設計的關鍵側面是 “單方面退出（unilateral exit）” 的概念。在任一時間，任何一方都要能夠從通道中強制退出、並在一個時延後拿回自己的資金。需要這個時延，是因為某一方可能會通過發佈舊的、已被撤銷的狀態到鏈上，也就是欺詐對手。這個時間窗口，讓誠實的一方可以駁回敵手的資金請求，具體辦法是證明自己知道一個僅在某一個狀態撤銷時才會被公開的秘密值。
這種從通道中單方面退出的能力，也是強制執行 HTLC 合約所需的關鍵模塊；HTLC 合約實現了 “要麼領走，要麼退款” 的功能，讓多跳的閃電網絡支付成為可能。這些合約帶有另一種時延模塊：以絕對時間點來決定的時延（絕對時間鎖）。在閃電網絡中轉發一筆支付的一條路徑上，每一跳都有 T 個區塊的時間窗口（CLTV 的時間鎖差值）來確認他們的承諾交易，以及讓久久不能結算的出賬 HTLC 超時。如果這些承諾交易無法及時確認，他們會因為 “單方贖回” 而冒資金損失的風險，因為接下來入賬的 HTLC 會超時，從而產生一個 超時/贖回 的賽跑。
（譯者注：在轉發一筆支付時，一個節點會從自己的上一個節點得到一個 “入賬 HTLC”，並向自己的下一個節點提供一個 “出賬 HTLC”。當下遊節點既不讓支付失敗、也不回傳原像、只是拖延，節點唯一的辦法就是讓承諾交易得到區塊確認，並在鏈上取回出賬 HTLC 的價值。但是，入賬 HTLC 也有個過期時間，一旦入賬 HTLC 過期，下游節點使用原像來領取出賬 HTLC 中的價值（參與手續費賽跑）就會導致節點的資金淨損失。所以，節點只有在入賬 HTLC 超時之前讓出賬 HTLC 得到區塊確認，才能避免這種 賽跑/淨損失。）
節點讓自己的承諾交易（在單方面退出時）得到及時確認的能力，依賴於他們作出有效的手續費預測的能力。如果承諾交易（它是不能單方面修改的）所攜帶的手續費不足，就無法及時得到確認（甚至不會被節點的交易池接受！）。當前，通道的發起者可以向對手發送 update_fee 消息，來提高（或降低）最新的承諾交易的手續費率。這是一種關鍵的工具，但是這就強迫發起者要麼準備好為承諾交易支付顯著過高的手續費（以保證總能夠在交易廣播後的下一個區塊中確認），要麼費盡心思預測未來的手續費率。因為發起人要支付承諾交易的所有手續費，響應者無法直接影響這個手續費，反而，在當前，如果他們不接受這個手續費水平，就只能嘗試強制關閉通道。
錨點輸出來了！
為了解決當前的承諾交易格式的部分缺點，人們提出了 “錨點輸出”【1】。大體思路是，雙方都可以在承諾交易中得到一個微小面額的輸出，是隻能由己方花費的（對方不能花費）；該粉塵輸出允許在事後為承諾交易追加手續費。這一設計放寬了預估手續費的要求，但並沒有完全消滅這種需要。現在，目標就不再是讓承諾交易在下一個區塊中確認，而是讓手續費高到足以進入節點的 交易池。一旦交易進入交易池，雙方都可以追加手續費、最終讓承諾交易確認。而且，這樣一來，我們還可以將兩階段的 HTLC 交易捆綁在一起，在清掃未結算的 HTLC 合約時實現更大程度的批處理。但是，進入交易池所需的手續費，也類似於進入下一個區塊所需的手續費，是不斷變化的。因為節點有一個默認的交易池空間上限，大約 300 MB，隨著進入的交易逐漸增多，節點也會開始拋棄一些費率最低的交易，從而讓進入交易池的手續費門檻升高。最後，現有的錨點交易可給出的最大手續費，可能也不足以進入交易池，這時候承諾交易也會被節點拋棄掉。這時候，想讓交易確認的節點就無法（使用現有的 P2P 網絡）來廣播自己的承諾交易了，意味著 TA 也許不能及時確認（甚至完全無法確認），因此無法避免賽跑。
沿著這條道路，開發者和研究者們發現了一系列跟交易廣播有關的微妙機理，以及實際上允許敵手將一筆交易 “釘死” 【2】在交易池中（故意阻撓其得到確認）的交易池轉發策略。已知的多種釘死攻擊界面都利用了跟 BIP 125 以及今天廣泛使用的交易池策略（多種祖先交易數量限制）有關的退化情形。
V3、TRUC 和 1P1C 來了（就是這一次）！
接下來是 “V3 交易” 和 “限制拓撲直至區塊確認（TRUC）”。閃電網絡開發者們的終極夢想是完全去除 update_fee，轉而讓承諾交易變成 零手續費。這可以將所有嘗試搞清楚應該設置多少手續費的猜測工作都拋在一邊。然而，如果單單這樣做，承諾交易攜帶零手續費的後果就是不會被交易池接受，因此也不會在比特幣 P2P 網絡中傳播。
TRUC（即 BIP 434）（一種新型的錨點輸出）以及 “樂觀的 1 父 1 子” 交易包轉發策略的結合，成了當前已知的最佳解決方案，可以實用地解決閃電網絡當前的交易轉發和確認問題。
TRUC 引入了一組新的交易替換規則，意在解決 BIP 125 在一小部分場景中的退化情形。此外，它加入了一組新的交易拓撲規模約束，以進一步限制問題。TRUC 交易使用版本號字段數值 3 （而不像 BIP 125 使用 sequence 字段）來表示交易自願使用這套新規則。
也是在 Bitcoin Core 28.0 中，一種新的標準公鑰腳本類型 “PayToAnchor（P2A）” 可用了【2】。P2A 是一種新的特殊隔離見證 v1 輸出（OP_1 <0x4e37>），意在用於 CPFP 手續費追加。花費這種輸出的輸入 必須 具有空的見證輸入，而且無需簽名就可以使用。這種新型輸出的未來版本可能最終會允許輸出變成粉塵，只要它們在被創造出來的同一個區塊中被花掉（通過 CPFP）。
這套新的承諾交易格式設計的最後一個模塊是：1 父 1 子（1P1C）交易包轉發【4】。1P1C 基本上就是機會主義的交易包轉發。它不是依賴於一種新的 P2P 消息（這可能需要時間來部署到整個網絡中），而是讓節點在收到孤兒交易（還不知道其輸入的交易）時改變行為。節點不會將這筆子交易存儲在孤兒交易池中，而是會選擇性地嘗試向報告該子交易的節點請求父交易，即使該父交易的手續費低於本地交易池的手續費門檻。
協同之下，這三種新的交易轉發原語可以用來重新設計閃電通道的承諾交易格式（即錨點），以解決上面提到的許多長期存在的問題。t-bast 已經開始設計新的承諾交易格式的原型了：x.com 。
雖說如此，還有一些為解決的問題，包括：
- 如何處理承諾交易的粉塵輸出？
- 使用 P2A 方法，我們可以將所有的粉塵都放到錨點輸出中，而不是像現在的做法，讓它們變成礦工手續費。這將解決一些跟粉塵輸出過量相關的已知問題，但也會帶來新的顧慮，因為 P2A 錨點輸出不需要簽名就可以花費。
- P2A 輸出應該變成 “無密鑰（keyless）” 形式嗎？
- 如果輸出是無密鑰的，那麼任何第三方都可以 立即 幫助清掃錨點輸出（相比於當前，只有參與通道的兩方可以立即清掃錨點輸出，直到錨點輸出被確認的 16 個區塊之後）。
- 與上面這一點相關的是，如果我們將所有的粉塵輸出放到 P2A 錨點中，那麼無論是誰，清掃了 P2A 錨點的人就可以拿走所有的粉塵輸出中的價值。天然地，礦工是最能可靠地申領其中資金的人，假設沒有簽名要求的話。
- 一些人認為，我們應該維持簽名要求，因為這能防止其他人干預嘗試讓承諾交易得到確認的參與者。這是為了對沖 TRUC+P2A 組合中出現未被發現的缺陷的風險（它們可能帶來尚未被發現的釘死攻擊風險）。
- V3 交易的病毒傳播特性是否會影響跟高級的通道拼接相關的某些應用場景？
- V3 交易的所有未確認後代都必須依然是 V3 交易。所以有人擔心這會影響通道拼接的使用，在一個節點嘗試用一個批量處理的交易來滿足多個交易流的時候。V3 交易類型的病毒傳播特性將迫使花費未確認的找零輸出的人都要繼續使用 V3 交易，這可能會超出他們的能力範圍。
新的 TRUC 規則也允許一種交易包 RBF，如果有一個新的衝突交易包進入，節點會嘗試對已有的交易包 RBF。在 1P1C 的語境下，這也被叫做 “親屬驅逐（sibling eviction）”【5】。
上述所有信息都可以在這本錢包開發者方便指南找到更多細節【6】。
對粉塵輸出的處理這可能是這次會議之後的更具體的新舉措之一。從這裡開始，我們將搞清楚新的 V3 承諾交易是什麼樣的，同時等待 P2P 網絡中足夠多的節點升級到新的版本，從而我們可以依賴新的轉發行為。
還值得指出的是，這種轉變將進一步影響閃電節點背後的錢包如何處理 UTXO 庫存。使用這種方法，給定承諾交易不會攜帶手續費，為了確認交易，節點 必須 使用一個既有的 UTXO 來錨定承諾交易，否則承諾交易甚至無法得到廣播。在實踐中，這意味著錢包需要儲備鏈上資金，以備及時強制關閉通道。通道拼接和潛水艇互換這樣的工具也可以用來允許錢包轉移資金，或批量處理多筆鏈上交互。
PTLC 與簡化的承諾交易格式
接下來的會議重點討論了 “點時間鎖合約（PTLC）” 與 “簡化的通道狀態機” 的結合。乍看起來，這兩個話題似乎沒有任何關聯，但我們很快就會看出來，PTLC 的設計考慮所帶來的一些棘手情形，可以通過修改當前的通道狀態機協議（姑且稱為 “閃電通道承諾協議（LCP）”）為一個簡化的變體來緩解。
首先，我們簡要介紹下 PTLC。在當前的閃電網絡協議中，我們使用支付哈希值來實現多跳的 申領或退化 裝置，從而允許信任最小化的多跳支付。雖然簡單，這種協議在隱私性上有一個大缺點：在構成整條轉發路徑的每一個通道中，承載支付的這個哈希值都是一樣的，所以如果一個敵手在路徑上佔據了兩個位置，就可以輕鬆地將一筆支付關聯起來（同時打破 “多路徑支付（MPP）” 循環）。
為了修復這個隱私性漏洞，許多年前，開發者們就提議切換到使用橢圓曲線和私鑰（替代支付哈希值和原像）。在 2018 年，一種正式的方案出現了【7】，該方案實際上允許使用跨 ECDSA 和 Schnorr 簽名方案的 “適配器簽名（adaptor signature）” 來實例化這種新構造。這很有趣，因為它意味著我們無需等待 taproot 升級激活（它將啟用 Schnorr 簽名）。相反，多跳的鎖可以在由 ECDSA 跳和 Schnorr 跳構成的路徑種傳輸。最終，出於各種原因，這種混合方法從未得到部署。好處是，我們可以部署一種更簡單、更統一、僅限 Schnorr 簽名的多跳鎖。
快進到現在，istagibbs 除了在研究 “對稱式閃電通道（LN-Symmetry）” 的具體設計以外，已經探索了各種設計空間，從消息傳播到狀態機插件【8】。
在討論了他的一部分發現之後，我們開始關注一些關鍵的設計問題：
我們應該使用基於單簽名還是多簽名的適配器簽名？在兩種方法中，用來創建簽名的適配器點
T都允許提議方補充簽名入賬 HTLC 所需的私鑰。基於 musig2 簽名算法的適配器簽名體積更小（最終只有一個簽名，而不是兩個），但加入了額外的協作要求，因為雙方都需要提供一個 nonce 值，以恰當地創建一筆新的承諾交易。
基於單簽名的適配器簽名更大（有兩個簽名，就像當前的兩階段 HTLC 交易一樣），但協議更簡單，因為 HTLC 簽名可以像往常一樣，跟
commit_sig一起發送。如果我們決定使用 musig2 適配器簽名設計，那麼，我們要嘗試保留當前的全雙工異步 LCP 流程嗎？還是應該進一步簡化，轉而使用一種簡單的同步承諾狀態機協議呢？
為兩階段 HTLC 交易引入 musig2 nonce 會讓現有的 LCP 協議更加複雜，因為我們將不再能夠隨
commit_sig消息一起發送兩階段 HTLC 交易的簽名，因為提議狀態變更的一方需要來自響應方的一個碎片簽名，才能安全地繼續。然而，如果我們修改通道狀態機協議，變成 基於輪次的，那麼，雖然我們犧牲了一些 x-put，但就不需要擔心怎麼處理可能出現的交錯執行（雙方同時發送
update_add_sig+commit_sig）了。這就引導了簡化流程的話題。
基於輪次的通道狀態機協議
在今天的閃電網絡協議中，我們使用一種全雙工的異步狀態機。這意味著雙方都可以隨時提議狀態變更，不需要預先跟另一方商量。任何時候，我們都可能有 4 種承諾交易： 對一方來說已經敲定的承諾交易，以及還未構造完成的承諾交易（收到了簽名，但還未發送撤銷秘密值）。假設雙方都繼續發送簽名並撤銷自己的舊承諾交易，最終雙方的 “承諾交易鏈條頭” 將覆蓋同一組正在進行的 HTLC。
這種設計對吞吐量很友好，因為即使雙方都在連接開始時發送多個撤銷秘密值，他們也可以繼續發送新的狀態，不需要等待對方，因為他們在一個滑動窗口（sliding window）中消耗撤銷點，每次對方法隆一個新的撤銷秘密值就能作廢掉一箇舊的狀態。它舊類似於 TCP 的滑動窗口的作用。
這種協議的一個缺點在於，在執行期間遇到分歧或錯誤時，是絕對無法恢復的。因為雙方都隨意發送更新（甚至在重發之後也還繼續這樣做），那就沒法暫停或倒回去，因此無法復原協議狀態。
一個例子是通道的儲備金（譯者注：餘額中不可動用的一部分，為了防止參與者在用盡餘額後可以發送任意已撤銷的承諾交易而沒有損失）。在當前的承諾交易中，無論哪一方要要添加一個 HTLC，通道發起人都要用自己的注資輸入支付手續費。然而，為了實際支付可能在任何時候出現的新 HTLC，通道發起人可能要用自己的通道儲備金來支付手續費。因為雙方都可以隨時提議 HTLC，為了防止這種棘手情形，他們需要給未來的 HTLC 留下足夠多的手續費緩衝資金。然而，很難準確估計對方未來的 HTLC。
如果我們有基於輪次的協議，那我們就能提前捕捉所有這些棘手情形，然後保證我總是可以恢復通道的執行、避免昂貴的強制關閉。這樣的基於輪次的協議將類似於基於 RTS（請求發送）和 CTS（允許發送）的流程控制協議【8】。
在正常的執行期間，雙方輪流提出對承諾交易集合的變更（添加或移除 HTLC）。如果一方沒有任何變更，可以讓對方先行。重要的是，在這種簡化後的協議中，雙方都可以顯式表示反對（NACK）或同意（ACK）一組變更。有了可以反對變更的能力，我們可以可以從出錯的流程中恢復，讓協議在應對假關閉需求時更加健壯。
如果我們使用基於 musig2 的 PTLC，那麼在基於輪次的執行中，雙方都可以提前發送 nonce 值，從而消除異步交叉交換 nonce 值的分析困難。另一個彩蛋是，這種協議可能容易分析得多，因為當前的狀態機協議是出了名地缺乏詳細描述。
鏈下的花式表演：SuperScalar、通道工廠及其它
在會議第一天的末尾，我們集中討論了利用 “共享 UTXO 所有權” 可以啟用的鏈下通道構造：鏈下通道創建、更便宜的自主保管移動錢包（吸引新用戶）、批量處理多方的交易執行。相關的提議包括：通道工廠、超時樹、ark、clark，等等。
一種最近出版的提議 SuperScalar【9】嘗試結合許多原語，解決用戶自主保管的移動端閃電錢包的 “最後一公里” 問題。SuperScalar 嘗試改變現狀，同時：保證 LSP（閃電網絡服務商）無法偷盜資金、不依賴於任何討論中的比特幣共識變更，並最終保持隨著系統進步而進步的能力，同時讓 部分/全部用戶 可以離線。
對 SuperScalar 最恰當的解釋是，它是三種技術的總和：雙工的微支付通道【10】、John Law 提出的 “超時樹（Timeout Trees）”【11】，以及一種階梯技術，讓 SuperScalar 實例的協調者可以分散資金並最小化機會成本。
我不會在這裡完整地介紹整個方案，相反，我建議有興趣的人看看上面引用的 Delving Bitcoin 帖子。在會議之後，Z 已經給他的方案提出了少許新的迭代，解決了部分短板並向不同的方向分叉。
概要地說，只要你把上述三者結合在一起，你就有了一大棵交易樹，每筆交易（葉子）都是一個常規的兩方通道，屬於 LSP 和一個用戶。從通道（葉子）開始，每往上一層，都是另一個由其子樹的參與者組成的多簽名裝置。每個葉子也都有一個額外的輸出，帶有額外的資金 L，可以用來為一條通道分配額外的流動性，只要 LSP 和用戶在線就行。如果更多參與者在線，那麼交易樹更高層的分支也可以重新簽名，從而允許在更大範圍內重新分配通道的容量。
這種階梯技術讓 LSP 可以在這種鏈下樹結構的多個實例中分配自己的資金。超時樹技術用於為所有用戶提供一個基於時延的退出路徑。這種構造不需要總是揭曉整棵交易樹來強制退出，在一段時間後，一個實例中的所有資金都會交給 LSP。這意味著，用戶需要跳轉到該構造的下一個 實例/階梯 中，就跟 Ark 構造中的共享 VTXO 的工作原理類似（它也使用了一種形式的超時樹）。結果是，這種構造中的所有通道都不再具有無限長的生命：用戶要麼將所有資金轉移出去，要麼跟 LSP 合作、在下一個實例中獲得一條新通道。否則，用戶將失去自己的資金。
SuperScalar 實例的生命可以分成兩個階段：活躍階段和消亡階段。在活躍階段，用戶可以正常使用自己的通道。他們可能會選擇提早退出實例，但在大部分時間都可以保持離線。在消亡階段，用戶必須來到線上、轉移資金或遷移到另一個實例中。它還有一種內置的安全窗口，一旦消亡期開始，LSP 將不再跟用戶協作更新交易樹，而且可能只會簽名出賬支付（LSP 是所有通道的一部分，但子通道也是可以實現的，需要額外的信任）。
回到額外的輸出 L，如前所述，輸出 L 是 LSP 可以隨意花費的。如果用戶需要額外的通道容量，那麼 LSP 就可以花費 L、跟目標用戶 A 創建一條新的子通道。不過，LSP 也能跟另一個用戶 B 簽名 L ，也就是 在鏈下 重複花費輸出 L 。這樣的花費只有一個版本可以出現在鏈上，本質上，這表明 LSP 已經透支，可能會偷盜資金，或者導致用戶損失自認屬於自己的資金。一種解決方案是使用一種如果簽名兩次就會導致私鑰曝光的簽名方案。有一些辦法可以構造出這樣的方案：OP_CAT，將簽名分解成 7 個以上的實例；或使用這篇論文所述的兩重適配器簽名方案【11】。
在較高層級中使用雙工的微支付通道意味著，隨著內部更新的數量增加，用戶為了從這種構造中強制退出而要發佈的交易的數量也會增加。與往常一樣，我們最終會遇到一個跟區塊鏈的經濟學相關的無可迴避的取捨：如果發起一筆支付的代價超過了這筆支付的價值本身，這筆支付就不會發生，或者發生在一種犧牲安全性以節約代價的系統中。換句話來說，對於用戶來說，在這樣的構造中擁有小規模的通道可能沒什麼意義，因為強制退出需要額外的手續費。為了讓小通道變得經濟，要麼協調者需要補貼它們，要麼用戶永遠不需要在鏈上展示它們，也就是總可以跳到下一個 SuperScalar 階梯上。
另一個有趣的話題是一種猜想：如果完全不使用任何鏈上交易，就不可能安全地在鏈下加入一條通道。要看出為什麼這很難，考慮這樣一種場景：Alice 和 Bob 已經有了一條通道，他們希望 Carol 也加入這條通道。Alice 和 Bob 創建了一個新的狀態，為通道的承諾交易加入了第三個輸出，就使用 Carol 的公鑰。Carol 向 Alice 和 Bob 請求一些信息，以說服她這就是最新的狀態，但實際上，A 和 B 總是可以偽造一些虛假的狀態更新歷史。因為根上的多簽名裝置只有兩個簽名者，A 和 B 總是可以重複花費掉給 Carol 的承諾交易、將她從通道中移除，還可以偷走承諾給她的餘額。你稍微想一想，就會發現這類似於 PoS 鏈中的 “nothing at stake（無本買賣）” 問題：A 和 B 偽造歷史來欺騙 Caorl 是沒有代價的。
這種不可能猜想的主要結論是：完全鏈下的動態成員資格（任何人都可以隨時進入、隨時離開）構造要求：要麼（1）信任根簽名人；要麼（2）某種類型的 歸責+懲罰 機制；或是（3）鏈上交易。第一類的解決方案包括：Liquid、Statechian 和帶有輪次外支付的 Ark。第二類解決方案，在過去一年中，我們看到了 BitVM 這樣的方案的出現，它依賴於 1-of-n 誠實參與者假設，利用了一種交互式鏈上欺詐證明來歸因和懲罰欺詐。在最後一類中，我會將這樣的構造歸類在內：Ark、SuperScalar 以及廣義來說 John Law 的超時樹。在最後一類方案中，用戶使用由鏈上交易創建的新輸出來驗證從葉子到根的一組 有效且不可更改 的交易，從而允許他們單方面召喚出自己的新通道。
總結起來，我認為，這一部分的有意義歸納是：
- 開發者和服務商都在尋找招攬用戶的新方法，希望鏈上足跡較少而且資本效率高。
- 有希望的解決方案似乎是以下技術的某種組合：通道工廠、超時樹、多方通道、臨時的鏈下資金交換協議（Ark 協議族）。
- 為了避免引入太多不必要的複雜性，任何新協議可能都要跟隨一種漸進式的部署計劃，按順序來交付模塊，每一個新模塊都建立在先前的模塊之上。
彩蛋環節：閃電演講
在會議的間隙，有一個閃電演講活動，人們可以講述自己在開發的任何有趣的東西。
這些演講中出現的一個很棒的電子是讓用戶能夠從虛假的強制關閉需求中復原。這樣的事情一直在發生，原因多種多樣，比如軟件實現之間的不一致，最常見的原因是手續費上的分歧。這裡的基本想法是給出一個額外的密鑰，讓對手在強制關閉通道時可以儘快花費自己的資金。這會是一種純粹的利他主義行動，代表沒有發起鏈上交易的一方，也是實在能幫到對手的友好行動。
從機制上講，實現這一點的一種辦法是盡最大努力幫助對手通過撤銷路徑來清掃輸出（跟通常用法相反）。一些人也討論了稍微修改輸出的派生構造、在通道重建消息中封裝新信息的方法。不廣播的一方將僅公開這些信息，在他們明確知道被髮布的是最新狀態並且已經得到確認的話。
讓 Gossip 不那麼煩人
在第二天早上，第一場會議討論的是定位 gossip 協議可以實現的具體提升。
Gossip 同步線索
閃電網絡的 gossip 協議有恰當定義的結構，但將許多關於行為的領域都留給了具體的實現。這樣的行為的案例包括：要維護多少個同步的對等節點？要不要限制進入的 gossip 消息的速率？如何驗證新進入的通道（如果有的話）？是否要定期抽查拓撲圖，找出缺失的通道？是否每次都要從頭下載所有東西？
在討論過程中，大部分時候，每個實現都從其他人那裡學到了自己沒有同樣實現的東西。每隔 幾個月/幾周，我們就會發現一些阻礙新通道更新或通道宣告傳播的微妙漏洞。LND 發現，他們最近作出的對曝光度和傳播幫助最大的提升就是開始在 gossip 查詢請求中使用通道更新的時間戳信息。沒有這種信息，節點就無法識別，即使他們跟對手方擁有同一組通道（基於 scid），對手方也可能擁有 更新的 通道。如果一種實現會修剪長期不活躍的 “殭屍通道”，卻不主動同步 gossip，然後如果他們不通過 gossip 查詢請求中的通道更新時間戳來抽查，那麼他們就無法找回舊的殭屍通道，然後弄丟網絡拓撲圖的一大部分。
Gossip 2.0
接下來，我們轉向新提出的對 gossip 協議的改造，代號為 “Gossip 2.5”（或者 “2.0”，就看跟你聊的人是誰了）。自上一次規範會議以來，LND 一直在推進規範【14】和實現【15】。當前，這份規範正在等待額外的 審核/反饋，而今年以來， LND 已經讓這套協議在 e2e 環境中工作（僅限新通道）。
我們討論的一個新的增項是在通道宣佈消息中添加 SPV 證據。一些實現要麼是有條件地，要麼是無條件地完全不驗證被宣告的通道的鏈上資金（前者例如 LND，要使用 --routing.assumechanvalid 標籤）。對於完全使用 P2P 網絡的輕客戶端（例如：Neutrino 客戶端），獲取區塊中幾萬筆交易可能是對 電源/帶寬/CPU 的巨大負擔。如果通道宣告消息可以攜帶（但總是承諾）一個 SPV 證據，那麼一條通道的存在性就可以僅靠最新的區塊頭鏈來驗證。如果只有 哈希摘要/最終負載的根 得到了簽名，那麼不需要額外證據的節點都可以請求發送方省去這些信息。在過去，LND 已經開發出了一種證據格式，支持在批量處理層面聚合，可能會被複用【16】。
至於互操作性測試，別的實現要麼現在有別的優先實現，要麼可能要等待上游庫的進展來集成 musig2（在本次開發者會議之後，musig2 在 libsecp 庫的 PR 就被合併了！）。今天還沒有一種主要實現支持 testnet4，所以它可能還沒有閃電通道，與會者都同意讓 testnet4 成為 gossip 2.0 的第一個試驗場！
Gossip 2.0 取消了舊的通道更新消息中中時間戳字段，代之以區塊高度。這簡化了速率限制，因為你可以規定一個對等節點每個區塊只能更新一次。因為區塊高度是全球統一的（沒有時區這樣的本地屬性），它更適合各種集合協調協議。多位與會者已經作了一些關於重新利用現有的 minisketch 實現的研究，雖然我們面臨不同的侷限，但可能最終會同時使用多個不同的東西。
（注：在此期間，我弄灑了咖啡在我的筆記本電腦上。為了排除故障，我錯過了好一部分討論。）
對支付分發的根本限制
然後，我們的一個會議討論了一些關於閃電網絡 尋路/路由 的最新研究。主要話題是一項 演示/討論，關於一些嘗試理解在支付通道網絡中分發支付的根本限制的新研究【[13](https://github.com/renepickhardt/Lightning-Network-Limitations/blob/305db330c96dc751f0615d9abb096b12b8a6191f/Limits of two party channels/paper/a mathematical theory of payment channel networks.pdf)】。
概要地說，這份研究將網絡拓撲圖建模位一系列的 邊 和 頂點，每一條邊都具有 3 種屬性：本地端的餘額、遠端的餘額，還有總的容量。給定一個樣本拓撲圖，我們可以確定一筆支付是否能送達：是否存在一系列的成對的餘額修改，能夠給予 “接收方” 所需的餘額結束狀態。該研究並不運行常規的基於貪婪的尋路算法，而是在全局上看待一筆支付的可行性。注意，這種方法自然捕捉到了支付期間強制再平衡的能力，可以讓原本無法滿足的支付流得以運行。
不可避免地，某些支付流是完全不可能實現的。理由包括：通道容量不充足、發送者沒有足夠多的餘額、接收者沒有足夠多的額度，等等。出現這種情形時，在這個模型內，就必須發生一筆鏈上交易，向網絡的活期餘額集合添加資金，或從中抽出資金。這樣的鏈上交易的例子包括：開啟一條通道、關閉一條通道、通道拼接或使用潛水艇呼喚。
基於上述防暑，給定一些起始假設（拓撲圖、餘額分佈、任意兩個節點之間支付可能性的樣本分佈），我們就可以得出該支付通道網絡的有效吞吐量的一種上限。為了得出這個數值（T），我們要用區塊鏈帶寬 TPS（Q）除以不可行支付的預期發生率（R），也即 T = Q/R 。如果我們想讓 T 為（比如說）47k TPS，那麼再代入當前主鏈的 TPS（大約 14），就可以得到 R 為 0.029%，即僅在 0.029% 的支付不可行的時候，才能達到 47k TPS。
最終，這些數字可以歸結為基於簡化了的假設的簡單數學計算。該模型沒有考慮的一個側面是可以批量處理鏈上交互，即，多個通道/用戶 可以用一筆鏈上交易來配置他們的鏈下 容量/帶寬。上面的推導也沒有考慮平衡式支付（例如，我在我的兩個節點間來回支付，不設手續費），這永遠不需要觸發鏈上交易，但也沒有計入 TPS 的推導種。不過，這樣的模型對於獲得對這個系統的侷限性的抽象感覺來說，還是有用的。
多方通道 & 信用通道
這份研究還定位了兩種原語，可以幫助減少不可行支付的數量：多方通道，以及網絡內部的授信（credit）。
多方通道在通道圖中聚合了多位用戶，實際上形成了一個新的充分連接的子圖。此處的直覺是：如果你將每一方向通道中添加的資金數量視為一個常數，那麼通過增加參與者的數量，你也提高了每一個用戶可以擁有的最大資金數量。而在提高這個最大數量的時候，就減少了因為 餘額/容量 的限制而不可行的支付的數量。
然後是積分，這個想法也很簡單：如果一筆支付是不可行的，那麼在某一些跳中，可以引入信用來永久或暫時地擴大一條通道的容量，同時增記某一方的餘額。為了儘可能降低系統性風險，這樣的信用似乎不應該引入網絡的核心，而只應該存在於邊緣。理論上，Taproot Assets 這樣的協議也可以用來提高支付的可行性，同時降低招攬用戶的成本，因為它讓用戶可以在通道中原生地表達 可尋址/可驗證 信用的概念。
吸引移動用戶的最後一公里問題
在結束的時候，我們有兩個獨立但相關的會議，關注移動端自主保管錢包的獲客和用戶體驗。首先，是 “最後一公里” 問題，因為它跟移動端用戶體驗和上手有關【17】。
在當前的閃電網絡中，絕大多數的使用體驗挑戰都來自於一個用戶嘗試給另一個用戶支付、但接收者使用的是自主保管的移動錢包。這就類似於互聯網基礎設施和帶寬中的最後一公里傳輸問題：網絡的內部包含具有高帶寬的 “寬鬆管道”，可以在內網中快速交換信息。然而，要將內網中的信息發送到最終目的地，就變得更貴、更不可靠，也更慢。
獲客成本 & 通道流動性
在閃電網絡的語境下，需要應對的不是老化的基礎設施，也不是高昂的建設成本，而是移動設備自身的各項特性。與持續在線的路由節點相比，移動節點需要被喚醒，以簽名新的入賬更新。此外，如果一個移動節點希望建成一個淨收款用戶（但還沒有主鏈資金，直接進入閃電網絡），那麼就要有一個路由節點為 TA 鎖定一行流動性。這第一條通道的建立從路由節點角度看是佔用資本，因為有可能這個移動節點從此就退出網絡，讓通道中的資金閒置。為了從長期離線的用戶手中收回資金，路由節點需要強制關閉通道、付出鏈上手續費和時間（等待相對時間鎖過期，最長可達 2 周）。
隨著我們深入最後一公里的流動性成本，我們開始遇上經濟效益的一些根本限制。如果一個在一條通道中只接收 10 聰，卻要付出 1000 聰（鏈上手續費）來開啟一條通道，那麼跟這樣的用戶創建連接就會導致路由節點的淨損失（就不要說今天網絡上還存在對通道最小容量的限制了）。路由節點分配給一個不活躍用戶的任何資本（收款額度）都可以轉而分配給網絡中的高速通道，在其中賺取路由手續費來彌補開設通道的成本。假設成本可以平攤，補貼可以持續，那麼基礎設施工具有：Phoenix Wallet 的 JIT 通道系統、Liquidity Ads【18】、使用 Lightning Pool 的 Sidecar Channel、Amboss 的Magma，等等。
由協議引起的用戶體驗問題
除了在線交互要求和鏈上手續費，當前的協議設計也有一些抽象缺失，最終進入到了終端用戶的移動錢包，成了獲客成本。一個例子是通道儲備金：為了保證雙方在全生命週期中都有所顧忌（威懾欺詐企圖），他們必須總在通道中保留少量餘額（通常是約 1%） 。這會讓用戶坤然，因為他們常常想要轉走錢包中所有的餘額，以遷移到另一個錢包，但轉過頭他們會發現自己總是要保留少量資金。此外，隨著鏈上手續費的上漲，符合經濟效益的通道容量也隨之上漲。
流動性費用回扣
最近出現的對 粉塵/小額輸出 問題的一種解決方案是 phoenixd【21】所用的一個概念，叫做 “手續費回扣（fee rebates）”。手續費回扣是一種不可返還的支付，用於購買未來的收款額度。每當一個用戶從一個特殊的路由節點（支持這種協議插件的節點）收到資金、但這個用戶又還沒有通道時，這筆資金會進入這個手續費回扣罐。一旦用戶在這個回扣罐中積累得到足夠多的資金，路由節點就會跟 TA 開啟一條通道，並用罐中的回扣來支付服務費和鏈上手續費。開設通道所需的最低金額將因服務和鏈上手續費的不同而不同。
從實用主義的角度看，手續費回扣能很好地工作。假設一個用戶最終能收到足夠多的錢，那他們可以立即收到這些資金，無需等待通道開啟。一旦他們有足夠多的資金來形成一個 L1 UTXO，那麼他們可以用手續費回扣罐支付，以創建這個 UTXO 。這種技術可以結合 ecash 這樣的系統（用鑄幣廠中的金額來表示待處理資金），或甚至是使用 Taproot Assets 的信用通道（使用在一個 Pocket Universe 中表示的資產 UTXO 來衝抵 L1 上的手續費）。
這時候，討論又回到了多種跟通道工廠類似的鏈下構造，以及它們在特定的鏈上手續費、用戶數量和這些用戶的餘額分佈環境下的侷限性。基本上，如果你想象某種這樣的構造，基於超時樹，然後，如果有 1 億用戶，每個用戶都只有 1 聰，那麼在鏈上展開整棵樹對他們來說是不划算的（因為手續費就已經超過了 1 聰）。如果我們想象有一種內置的機制，讓用戶可以將資金遷移到別的地方，從而協調員可以一次性領走所有資金（類似於 Ark 的模式），那麼如果用戶都沒能及時退出，那麼這 1 BTC 就會被協調員沒收。所有用戶都嘗試讓資金回到鏈上，就等同於燒掉所有資金，所以一些與會者想象了一種 “紅色大按鈕”，可以用來燒掉所有的現存餘額。理想情況下，這樣的燃燒需要某種腳本（或客戶端）可以驗證證據，讓協調員無法欺詐。
雖然上述場景或多或少只是一種思想實驗，我認為，它嘲笑了我們在面臨鏈上手續費以及小額 UTXO 時的一些根本侷限性。這裡沒有什麼新鮮事，這種機理正是為什麼絕大部分全節點都會默認粉塵輸出的概念：要花掉一個 UTXO 價值的 1/3 來支付手續費（以轉移其中的價值），是不划算的。鏈下系統也是同理，只有某種補貼或外生的價值系統能作為救生艙。任何在主鏈（或者在更高層級）上不經濟的轉移，都將不可避免地遷移到某些其它依然使用 BTC 作為記賬單位、但犧牲安全性以換得更便宜手續費的系統中。
BOLT 12：下一步是什麼？
濃霧瀰漫，美食環繞，你可暢享冷飲和壽喜燒，然後 BOLT12 的 PR 就合併到閃電網絡規範倉庫了！這一天的早些時候，作為會議的最後一場，我們討論了 BOTL 12 的下一步，也即從原始版本中砍掉的哪些插件是什麼想要的。
潛在的 BOLT12 插件
第一種被討論的插件是：發票替換。考慮一種場景：一個用戶使用一個 Offer 獲得了一張發票（invoice），但過了很久才支付，所以全部的盲化路徑 以及/或者 發票自身都過期了。在這種場景中，如果用戶能夠請求一張替換髮票，那就很有用。具體這跟直接用 Offer 請求另一張新的發票有何區別，可能是一個語境問題。
一些實現者最想要捲土重來的領域是：週期性支付（recurrent payment）。週期性支付的一部分曾進入最初的規範，但最終還是被刪去了一些。週期性支付相關的參數包括：時間間隔、支付窗口、限額、以及開始和結束時間。接收者可以使用的一個小技巧是利用哈希鏈條來最小化需要存儲的原像數量。如果他們可以給發送者交付一個特殊的 鹽/種子（在初始化協調期間），那麼只有發送者和接收者會知道這些原像能恰好構成一個哈希鏈條。
至於身份鑑別，人們提出了 BIP 353 的一種反向版本。基本的想法是，讓用戶可以將一個節點的公鑰綁定到一個域名。這可以用來鑑別節點 Y 跟某些 服務/域名/公司 相關聯。
洋蔥消息速率限制和背壓傳輸
在會議的末尾，注意力轉移到洋蔥消息，以及幾種主要的實現的 實現/行為 現狀。一個話題是錢包如何處理後備（fallback）以及相關的用戶體驗影響，當一個錢包 無法 獲得 Offer 的時候。洋蔥消息是一種不可靠的、雖然會盡最大努力但沒有任何內置的反饋機制的網絡，所以，有可能一條消息永遠不會送達。因此，錢包需要準備好：要麼嘗試另一條路徑，重新發送消息，要麼以某種其它機制為備選方案，在錢包請求失敗時轉而使用備選方案。
普遍來說，現狀是使用一個單跳的洋蔥消息路由，或者直接連接。“直接連接” 指的是在 P2P 中直接連接接收者、盲化路徑的入門節點，或者連接到入門節點的節點，以嘗試用更短的路徑發送消息。如果 這些 嘗試也都失敗（沒有節點監聽、或者接收者不在線，等等），節點就要麼需要其它的後備方案，要麼嘗試發送某種形式的自發付款（spontaneous payment）。
回到消息傳遞，很明顯需要某種速率限制。節點可能一開始就有一些免費的預算，但需要限制消息傳遞，否則一個節點可能在不知不覺中免費轉發了 10 GB 的洋蔥消息流量（在我看來，在一個免費層之後，大多數節點最終都要切換成度量帶寬的支付系統【22】）。因此，節點需要採用某種帶寬和速率限制。如果網絡相對於典型的消息傳遞使用情況明顯超量供應，那麼服務將保持相對較高的水平，因為使用量還沒夠到配置好的帶寬限制。然而，如果網絡與消息傳遞活動相關（人們試圖直播他們的遊戲會話或諸如此類的活動），那麼服務就會受到阻礙，因為大多數發送消息的嘗試都會因為公地悲劇而失敗。而且，消息被丟棄、未交付或接收者離線之間的差異都是無法區分的，這進一步給用戶體驗帶來了挑戰。
最終討論轉向了先前在郵件組中提出的舊的背壓速率限制算法（back pressure rate limiting algorithm）【23】。雖然使用該算法，節點可以保存一個相對緊湊的描述，關於最後向其發送消息的對等節點。一旦某個對等節點超過限制，節點就會向流量發送方發送一條 onion_message_drop 消息。然後，發送方會嘗試追蹤向自己發送消息的人，並進一步向後傳播 onion_message_drop 消息，從而將過程中的速率限制減半。如果發送方在 30 秒間隔內沒有溢出速率限制，則接收方應將其速率限制加倍，直到達到正常速率限制。
這裡仍然存在一些開放問題，例如：節點如何可以將氾濫消息正確歸因到某個對等節點？節點是否可以陷害其他節點、切斷他們的消息活動？是否還需要任何其他元數據才能正確確定氾濫消息的來源？對於知道這些速率限制、但依然嘗試在限制之下儘可能濫用帶寬的攻擊者來說，這套方案是否有抗性？這種方案剛剛出現的時候，為衡量該方案的效果和抗性，有人運行了一些基本的模擬【24】。初步結果令人鼓舞，也產生了一些額外的研究問題【25】。
最終，一些與會者同意開始恢復背壓算法的 工作/研究，並在短期內應用保守的速率限制參數。
