发表机构
School of Software & Microelectronics, Peking University; School of Computer Science, Peking University; School of AI and Liberal Art, Beijing Normal-Hong Kong Baptist University（北京大学软件与微电子学院; 北京大学计算机科学与技术学院; 北京师范大学-香港浸会大学联合国际学院人工智能与文学院）
机构由 AI 辅助整理，请以论文原文为准。AI 中文总结
针对闪电网络池化流动性中的全局不变量执行难题，Sluice采用嵌套预留与证书机制，在无罚没质押下防止超额支取，恢复池化收益19%-65%，并将协调成功率损失控制在1.3点以内。
AI 中文摘要
闪电网络上的路由节点将其流动性分散持有在各自独立的通道中，因此当某条通道的出站余额耗尽时，即使该节点的其他通道仍有余额，支付也可能在该通道失败。将各通道合并为一个储备池可以解决此问题，但前提是节点在所有通道上的支取总额不超过该储备池：这是一个全局不变量，每个对手方必须在其自身通道内执行，且没有可被链下支取更新的共享计数器。因此，节点必须预先将储备池拆分为各通道配额，或与每个对手方协调每次支取。在三个闪电网络快照上，预先拆分相比未池化通道损失了池化收益的16%至67%，且损失随通道数量增加而增长。Sluice通过嵌套预留机制恢复了该损失的19%至65%：每条通道保留一个由对手方单独检查的专属基础额度，其余部分作为共享溢出额度，通过来自节点对手方中按容量加权的法定人数的证书进行支取。两个冲突的证书共享一个诚实签名者，因此在所声明的节点在签名集中控制的容量上限下，无需可罚没的质押即可防止超额支取。Sluice在协调方面最多损失1.3个百分点的支付成功率，而部署的币转移器损失高达10.3个百分点；当叠加在它们之上时，在十二个单元中的十一个上有所改进。每个纪元重新创建所有基础输出消耗的链上字节是闪电网络的2.8至5.1倍；仅重新创建发生溢出的那些消耗0.5至1.2倍，并保留了部分收益。
英文摘要
A routing node on the Lightning Network holds its liquidity in separate channels, so a payment can fail at a channel whose outbound balance is exhausted while the node's other channels still hold balance. Pooling the channels into one reserve fixes this only if the node's draws across all channels stay within the reserve: a global invariant that each counterparty must enforce from its own channel, with no shared counter that off-chain draws can update. A node must therefore split the reserve into per-channel quotas in advance or coordinate every draw with every counterparty. On three Lightning snapshots the advance split forfeits $16$ to $67\%$ of the pooling gain over unpooled channels, and the loss grows with channel count. Sluice recovers $19$ to $65\%$ of that loss with a nested reservation: each channel keeps an exclusive base that its counterparty checks alone, and the rest is a shared overflow drawn on with certificates from a capacity-weighted quorum of the node's counterparties. Two conflicting certificates share an honest signer, so over-drawing is prevented without a slashable stake, under a stated bound on the capacity the node controls in the signing set. Sluice loses at most $1.3$ points of payment success to coordination where deployed coin movers lose up to $10.3$, and improves them in eleven of twelve cells when stacked on them. Re-creating every base output each epoch costs $2.8$ to $5.1$ times Lightning's on-chain bytes; re-creating only those that overflowed costs $0.5$ to $1.2$ times and keeps part of the gain.
