多方支付管道：探索可靠性和鏈上成本之間的權衡

Rene Pickhardt 最近發起了一個帖子，討論兩方和多方（超過兩個參與者）支付管道之間的差異，因為它涉及

Rene Pickhardt recently kicked off a thread discussing the differences between two party and multiparty (more than two participants) payment channels as it relates to his research work around payment reliability on the Lightning Network. He voices a growing skepticism of the viability of that direction for development.

Rene Pickhardt 最近發起了一個帖子，討論兩方和多方（超過兩個參與者）支付管道之間的差異，因為這與他圍繞閃電網絡支付可靠性的研究工作有關。他對這一發展方向的可行性表示越來越懷疑。

The high level idea of why channel factories improve the payment reliability comes down to liquidity allocation. In a network of only two party channels, users have to make zero sum choices on where to allocate their liquidity. This has a systemic effect on the overall success rate of payments across the network, if people put their liquidity somewhere it isn’t needed to process payments instead of where it is, payments will fail as the liquidity in places people need is used up (until it is rebalanced). This dynamic is simply one of the design constraints of the Lightning Network known from the very beginning, and why research like Rene’s is incredibly important for making the protocol/network work in the long run.

為什麼渠道工廠提高支付可靠性的高層想法可以歸結為流動性配置。在只有兩方管道的網路中，使用者必須在哪裡分配流動性方面做出零和選擇。這對整個網路支付的整體成功率產生系統性影響，如果人們將流動性放在不需要處理支付的地方而不是原來的地方，那麼隨著人們需要的地方的流動性被用完，支付就會失敗（直到重新平衡）。這種動態只是閃電網路從一開始就已知的設計限制之一，也是為什麼像雷內這樣的研究對於使協定/網路長期運作非常重要。

In a model of multiparty channels, users can allocate liquidity into large groups and simply “sub-allocate” it off-chain wherever it makes sense to in the moment. This means that even if a node operator has made a poor decision in which person to allocate liquidity to, as long as that person is in the same multiparty channel with people that would be a good peer, they can reallocate that poorly placed liquidity from one to the other off-chain without incurring on-chain costs.

在多方通路模型中，使用者可以將流動性分配到大的群組中，並簡單地將其在鏈下“子分配”，無論何時有意義。這意味著，即使節點運營商在向哪個人分配流動性方面做出了錯誤的決定，只要該人與良好同行的人處於同一個多方渠道中，他們就可以從一個人那裡重新分配流動性不佳的人。

This works because the concept of a multiparty channel is essentially just everyone in the group stacking conventional two party channels on top of the multiparty one. By updating the multiparty channel at the root, the two party channels on top can be modified, opened, closed, etc. while staying off-chain. The problem Rene is raising is the cost of going on-chain when people don’t cooperate.

這是可行的，因為多方通路的概念本質上就是團隊中的每個人都將傳統的兩方管道堆疊在多方管道之上。透過更新根部的多方通道，頂部的兩方通道可以在保持鏈外的情況下進行修改、打開、關閉等。 Rene 提出的問題是當人們不合作時上鍊的成本。

The entire logic of Lightning is based around the idea that if your single channel counterparty stops cooperating or responding, you can simply submit transactions on chain to enforce control over your funds. When you have a multiparty channel, each “level” in the stack of channels adds more transactions that need to be submitted to the blockchain in order to enforce the current state, meaning that in a high fee environment multiparty channels will be more expensive than two party channels to enforce on-chain.

閃電網路的整個邏輯基於這樣的想法：如果您的單一管道交易對手停止合作或回應，您只需在鏈上提交交易即可強制控制您的資金。當您擁有多方通道時，通道堆疊中的每個「層級」都會添加更多需要提交到區塊鏈的交易，以強制執行當前狀態，這意味著在高費用環境中，多方通道將比兩個通道較昂貴各方通路在鏈上強制執行。

These are core trade-offs to consider when looking at these systems compared to each other, but I think focusing exclusively on the on-chain footprint ignores the more important point regarding off-chain systems: they are all about incentivizing participants to not go on-chain.

這些是在比較這些系統時需要考慮的核心權衡，但我認為僅僅關注鏈上足跡忽略了關於鏈下系統的更重要的一點：它們都是為了激勵參與者不要繼續下去-鏈。

Properly structuring a multiparty channel, i.e. how you organize the channels stacked on top, can allow you to pack groups of people into subsections that have a reputation for high reliability, or who trust each other. This would allow people in these subgroups to still reorganize liquidity within that subgroup even if people outside of it are not responsive temporarily, or go offline due to technical issues. The on-chain cost of enforcing things, while important, is kind of tangential to the core design goal of an off-chain system: giving people a reason to stay off-chain and cooperate, and removing reasons for people to not cooperate and force things onc-chain.

正確建立多方管道，即如何組織堆疊在頂部的管道，可以讓您將一群人分成具有高可靠性聲譽或相互信任的小組。這將允許這些子群體中的人們仍然可以重組該子群體內的流動性，即使子群體之外的人暫時沒有回應，或者由於技術問題而離線。執行事情的鏈上成本雖然很重要，但與鏈下系統的核心設計目標有點相切：給人們一個留在鏈下和合作的理由，並消除人們不合作和強迫的理由事物上鍊。

It’s important to not lose sight of that core design aspect of these systems when considering what their future will look like.

在考慮這些系統的未來時，重要的是不要忽略這些系統的核心設計面向。