目前閃電路由實現的可擴展性如何？
目前閃電路由面臨哪些弱點？
我們希望它現在可以處理多少個節點？
正在做些什麼來使其在未來擴大規模？
我不確定在討論路由的潛在問題時，規模是否是您正在尋找的術語。但在給出答案時，我會盡量專注於縮放。話雖這麼說，如果以不同的方式提出問題，我的答案可能會有很大差異。
目前的路由算法是洋蔥路由。洋蔥包含從發送者到接收者的路徑（由發送者決定 - 有關詳細討論，請參見下文），並且建構為支持多達 20 個躍點。這意味著我們實際上可以擴展到直徑為 20 的網路。（直徑是友誼網路上最長的最短路徑，是一個拓撲屬性）。已經有了 21 個節點，我可以創建一個具有列表拓撲結構的閃電網路，並且無法使用目前的洋蔥格式將支付從列表的頭部路由到尾部。這個問題可以通過創建一個新的支付渠道來輕鬆緩解——以一種減少直徑的方式改變拓撲。我的自動駕駛儀實施建議減少網路直徑的通道。
所以問題歸結為直徑小於 20 的網路可以有多大？在查看大型網路（如 web 或 Facebook 圖表）的強連接組件時，它們的直徑似乎都較小，這表明 20 跳限制不應阻礙規模。但是有一個相關性：在具有固定節點集的網路上，我們允許的邊越多，直徑越小。取一個定義為直徑為 1 的完全連接的圖，與上面的“列表圖”相比，它的直徑為
n。話雖如此，Facebook 上的網路圖和友誼圖也被認為每個節點平均有大約 150 條邊（所謂的鄧巴數）。我們已經知道，如果沒有通道工廠和目前的塊大小限制，我們將需要數十年的時間才能讓世界上的每個人都打開一個支付通道，這很可能會產生一個直徑更大的圖表。讓人們打開 150 個頻道需要 150 倍的時間。
就路由規模而言，洋蔥不僅有 20 跳的限制。還有尋路並與網路拓撲的發現相關（又名八卦協議）。路徑查找歸結為廣度優先搜尋或加權 BFS 的 Dijkstra 算法。這兩種算法都有一個執行時，可以在現代硬體上具有數十億個節點的圖上進行部分查找，特別是在使用像 neo4j 這樣的圖數據庫時（目前所有內容都儲存在記憶體中）。如果網路將超出人類節點（例如物聯網節點），我們可能會達到現代硬體的極限來計算這些路徑。
至於八卦協議。每個通道都需要向對等網路宣布。由於通道需要驗證/連結到區塊鏈交易，這應該不是問題。然而，八卦協議似乎很嘈雜。目前有生鏽的羅素（Rusty Russell）執行的百萬節點挑戰賽，試圖刺激如果網路增長會發生什麼。
還有潛在的其他問題，例如每個支付渠道 483 個並發 htlc 的 htlc 限制，這可能會導致交通堵塞（儘管這似乎不太可能，實際上是避免這些所謂的集中式集線器以及為什麼節點應該努力減小直徑的原因）。網路的確切拓撲也永遠未知（僅通道容量）
關於您的第二部分（問題如何緩解） 1. 最大的問題似乎是快速打開渠道。Christian decker 的研究提出了通道工廠的概念，表明我們可以將每個塊可以打開的通道數量增加 10 到 100 倍。 2. 至於尋路：我目前建議 JIT-routing，這是一個低路徑發現的水平向後兼容改進。這種路徑發現機制緩解了選擇路徑時不知道通道平衡的問題。我的建議還包括讓節點只儲存網路的本地視圖並創建可用於路由表的覆蓋定址方案（就像它在 Internet 上一樣），這也將緩解儲存整個網路的問題。3.
可能還有更多我目前不知道的問題。