原文標題：《科普 | 閃電網路的入賬容量問題》
撰文：Florencia Ravenna
翻譯：阿劍
幾個星期以來，比特幣社區的很多人一直在討論閃電網路（Lightning Network）的 inbound capacity 問題。越來越難以收到閃電火炬，加上 Bitrefill 啟動了 Thor，還有 LND 放出了 Lightning Loop，都讓人們更加關注這個問題。在本文中，我會解釋這個問題的形式及其根源。我們也會分享一些很容易被忽略的洞見。
本地和遠端的余額
要理解入賬容量，我們得先深入了解閃電網路的第一個基本模塊：支付通道。這個概念可能你在之前也聽過了，所以我們直接跳到跟入賬容量有關的部分。
我們先考慮一個單獨的通道，然后慢慢提高思考的復雜度，
一個支付通道開通后，它就鎖住了恒定數量的一些 btc，這個數量叫做 「 通道容量 」。參與支付通道的雙方各自擁有這個容量的一部分，在你自己這邊的余額，我們叫 「 本地余額 」，而在你的交易對手那邊的余額，叫 「遠端余額 」，你的本地余額和遠端余額在關閉通道之前可以更新任意次，但通道容量，如果你不關閉通道或者拼接通道，是無法改變的。
支付通道就像沙漏：雖然沙子的總量是恒定的，你可以任意把沙子移動到其中一端，但如果你想改變里面沙子的數量，那就非打破這個沙漏不可
你跟 Robert 的通道里面有 8 btc，你的本地余額是 5 btc，你的遠端余額是 3 btc
每次支付，都是把你的本地余額轉一些給你的交易對手，也就是減少本地余額，增加遠端余額。類似地，當你收到一筆支付時，你的本地余額增加，數額恰好等于你的遠端余額減少的數額。
當你給 Robert 支付 1 btc 之后，你的遠端余額增加了 1 btc
入賬和出賬的容量
現在，我們更清楚地理解了什么決定了通道的容量，以及本地和遠端余額是怎么更新的，現在來想想，如果你是一個閃電網路的節點，是網路的一部分，將有何區別。
兩個交易方并沒有直接相連的支付通道，但是，他們可以通過 路由節點 來支付，在整個支付路徑上，每一次中轉都要用到一個雙向的支付通道。因此，我們剛剛講到的支付通道特性適用于每一次中轉，
假設你想通過閃電網路來賣貼紙，那么，你需要與至少一個閃電網路節點建立連接，你仔細挑選了一個節點，保證這個節點可能跟你的潛在客戶 Sophie 和 Angela 相連。我們把這個節點叫做 「lnTop」。
你跟 InTop 開啟了一個通道，鎖入了 2 btc。你的本地余額是 2 btc，遠端余額是 0 btc
現在，Angela 想要買一些你的貼紙，并通過 lnTop 來支付，但是，你跟 lnTop 的通道中，你的遠端余額是 0 呀，lnTop 并不能給你支付。因此，lnTop 無法路由這筆交易。
在一個時間點上，你可以收到的 btc 數量（也就是 「入賬容量」），是由你的遠端余額決定的，很簡單嘛，如果你相連的節點只能發送 1 btc 給你，你是沒法收到比 1 btc 更大的數額的，類似地，你可以發送的 btc 數量（「出賬容量」）是由你的本地余額決定的，
在你決定跟 lnTop 開啟一個通道時，你需要確定自己想鎖定多少 btc 進去，也即你初始的本地余額是多少。lnTop 也一樣，他們的選擇決定了你初始的遠端余額。這就有了一個重要影響，雖然你能夠決定自己的初始本地余額（自己的初始出賬容量），但你沒法控制自己的初始遠端余額（和入賬容量），
如果你今天要啟動一個自己的閃電網路節點，并且只是隨隨便便地選了一個節點來開啟通道，你可能會發現，你根本沒有入賬容量可用，即，你壓根沒法通過閃電網路來收到支付。聽起來對商人很不友好，對不對？
好消息是，你有很多辦法來提高自己的入賬容量，比如自己先發起支付，或者請求其他節點提供容量（并付錢給他們）。這篇文章講解了入賬容量問題的不同解決方案。
就這么簡單？
嗯 …… 也不是。即使你知道了自己如何能提高遠端余額，可能也沒法解決入賬容量問題。關鍵在于：并非所有通道的入賬容量都相同。要理解這一點，你要先理解，在支付路由的過程中，閃電網路的其它部分，發生了什么事情，我們把上圖所示網路的通道容量都劃出來，這樣更好理解了。
這是 lnTop 往通道里充值了 3 btc 之后的情形，在網路中，所有節點都跟自己相連的節點有專門的本地和遠端余額
你從 lnTop 那里獲得一些入賬容量之后，Angela 最多也只能給你發 2 btc，因為你在 lnTop 那里的入賬容量超過了 2 btc，但 lnTop 在 Angela 處的入賬容量只有 2 btc。
但是，在這個網路里，Sophie 就沒法給你發送 1 btc，你可以看看 Sophie 給你支付的路徑上的通道容量狀態，你的確有 3 btc 的入賬容量，但 lnTop 沒有 lnFirst 的入賬容量。
對于支付，每個參與路由的節點和你（接收方）都必須跟上一個節點有足夠的入賬容量。所以，雖然你能解決跟相鄰節點 lnTop 的入賬容量問題，但 lnTop 可能跟相鄰的節點沒有足夠的入賬容量。Lightning Labs 的閃電網路基礎設施總監 Alex Bosworth 幾周以前指出了這個問題，
還有一個事實，讓這個問題很難解決。那就是，「揭示所有節點的本地和遠端余額」 這件事，在閃電網路上是做不到的，作為網路中的一個節點，你只知道通道容量，并不知道這部分容量在兩個參與者之間是如何分布的。
誰會受這個問題影響？
閃電網路中，并非所有的節點都有相同的需要。從上面的例子中，我們可以辨認出至少 3 類節點，
商家節點
我們用 「商家節點」 來稱呼那些主要是收賬的節點。在上面的例子中，「你」 就是一個收賬節點，因為你最關心的就是收到貼紙買家的支付。因此你需要入賬容量，記住：不僅你要有足夠的入賬容量，買家到你的整個支付路徑上的節點都必須有足夠的入賬容量才行，
終端用戶節點
這些節點主要使用閃電網路來發賬。偶爾他們會從朋友或者閃電應用處收到錢。Sophie 和 Angela 都是終端用戶。對于這個群體，關鍵是要連上資金充足而又與商家相連的節點。他們既需要入賬容量，也需要出賬容量，全看他們在特定時間的需要，
路由節點
這些節點是路由支付并從中賺取手續費的節點。LnTop 和 lnFirst 都是這樣的節點，他們的工作是發現有需要的收款方，比如你，小鎮上最大的貼紙商家，對終端用戶，他們需要足夠的入賬流量；對商家，他們需要出賬容量，此外他們還得跟市場上的其他服務商競爭，要確保自己總是在線，賺點錢不容易，對吧？
結論
我們從單一通道開始討論，講解了網路內通道的特點，最終使用 「節點資訊全公開」 的假設討論了入賬容量問題，
我們將入賬容量定義為給定時間點在閃電網路中你可以收到的 btc 數量，并推論了它依賴于你的遠端余額，
入賬容量問題可能是閃電網路在啟動階段會遇到的問題。因此，如果流動性在整個網路中的分布更充分、更好，問題將減輕。我們會繼續撰文探討閃電網路在早期會遇到的問題，
