Lightning & SkalierungLightning & ScalingLightning & EscalabilidadLightning & EscalabilidadeLightning & スケーリングLightning & 扩容Lightning & التوسع
Splicing, Channel Factories und PTLCs: Wohin sich das Lightning Network entwickeltSplicing, Channel Factories, and PTLCs: Where the Lightning Network Is HeadedSplicing, Channel Factories y PTLCs: Hacia dónde se dirige el Lightning NetworkSplicing, Channel Factories e PTLCs: Para onde o Lightning Network está indoSplicing、Channel Factories、PTLC：Lightning Networkの進化する方向性Splicing、Channel Factories 与 PTLC：Lightning Network 的发展方向Splicing وChannel Factories وPTLCs: إلى أين يتجه شبكة Lightning
Die Kernfakten zu Splicing (BOLT #863, CLN-Implementierung), PTLCs (Schnorr/Adaptor-Signaturen) und Channel Factories (Burchert et al. 2018) sind gut durch primäre Quellen belegt. Der Implementierungsstand 2026 (LND noch in Entwicklung, keine produktiven Channel Factories) basiert auf dem Recherche-Briefing und ist als Momentaufnahme einzustufen. 'likely' statt 'verified', da der Entwicklungsstand Protokoll-Ebene sich schnell ändert und keine unabhängige Kreuzverifikation aller Implementierungsdetails vorliegt.Core facts on Splicing (BOLT #863, CLN implementation), PTLCs (Schnorr/adaptor signatures), and Channel Factories (Burchert et al. 2018) are well-supported by primary sources. The 2026 implementation status (LND still in development, no production Channel Factories) is based on the research briefing and should be treated as a snapshot. 'likely' rather than 'verified' because protocol-level development status changes rapidly and no independent cross-verification of all implementation details is available.Los hechos fundamentales sobre Splicing (BOLT #863, implementación CLN), PTLCs (firmas Schnorr/adaptadoras) y Channel Factories (Burchert et al. 2018) están bien respaldados por fuentes primarias. El estado de implementación en 2026 (LND aún en desarrollo, sin Channel Factories en producción) se basa en el informe de investigación y debe considerarse una instantánea en el tiempo. Se usa 'likely' en lugar de 'verified' porque el estado del desarrollo a nivel de protocolo cambia rápidamente y no se dispone de una verificación cruzada independiente de todos los detalles de implementación.Os fatos centrais sobre Splicing (BOLT #863, implementação CLN), PTLCs (assinaturas Schnorr/adaptadoras) e Channel Factories (Burchert et al. 2018) são bem sustentados por fontes primárias. O estado de implementação em 2026 (LND ainda em desenvolvimento, nenhuma Channel Factory em produção) baseia-se no briefing de pesquisa e deve ser tratado como um retrato momentâneo. 'likely' em vez de 'verified', pois o estado de desenvolvimento no nível de protocolo muda rapidamente e não há verificação cruzada independente de todos os detalhes de implementação disponível.Splicing（BOLT #863、CLN実装）、PTLC（Schnorr/アダプター署名）、Channel Factories（Burchert et al. 2018）に関する核心的な事実は、一次資料によって十分に裏付けられています。2026年時点の実装状況（LNDはまだ開発中、本番稼働中のChannel Factoriesは存在しない）はリサーチ・ブリーフィングに基づくものであり、あくまでスナップショットとして扱うべきです。プロトコルレベルの開発状況は急速に変化し、すべての実装詳細について独立したクロス検証が行われていないため、'verified'ではなく'likely'としています。关于 Splicing（BOLT #863，CLN 实现）、PTLC（Schnorr/适配器签名）及 Channel Factories（Burchert et al. 2018）的核心事实均有充分的一手资料支撑。2026 年的实现现状（LND 仍在开发中，尚无生产级 Channel Factories）基于研究简报，应视为阶段性快照。标注为"likely"而非"verified"，原因在于协议层面的开发进展变化迅速，且目前尚无针对所有实现细节的独立交叉验证。الحقائق الأساسية المتعلقة بـ Splicing (BOLT #863، تنفيذ CLN)، وPTLCs (تواقيع Schnorr/Adaptor)، وChannel Factories (Burchert et al. 2018) موثقة توثيقًا جيدًا بمصادر أولية. وضع التنفيذ لعام 2026 (LND لا يزال قيد التطوير، ولا توجد Channel Factories في بيئة الإنتاج) مستند إلى ملخص البحث وينبغي اعتباره لقطةً آنية. تم اختيار 'likely' بدلاً من 'verified' لأن حالة التطوير على مستوى البروتوكول تتغير بسرعة، ولا تتوفر تحقق مستقل متقاطع لجميع تفاصيل التنفيذ.
Der Artikel zeichnet ein konsistent positives Bild dreier Protokollerweiterungen, ohne die strukturellen Rückschläge der letzten Jahre einzuordnen: Channel Factories werden seit 2018 diskutiert – acht Jahre ohne produktive Implementierung sind kein Zufall, sondern Ausdruck eines grundlegenden Anreiz- und Koordinationsversagens bei n-of-n-Multiparty-Protokollen. PTLCs scheiterten bislang nicht an fehlendem Taproot, sondern an der mangelnden Einigung der großen Implementierungen auf ein gemeinsames Update-Protokoll. Wer den Implementierungsstand 2026 als "planbar, aber langsam" beschreibt, unterschätzt das realistische Risiko, dass Channel Factories und PTLCs im beschriebenen Zeithorizont gar nicht kommen – eine Perspektive, die im Text vollständig fehlt.The article consistently presents three protocol extensions in a positive light without contextualizing the structural setbacks of recent years: Channel Factories have been discussed since 2018 – eight years without a production implementation is not coincidental, but reflects a fundamental incentive and coordination failure inherent to n-of-n multiparty protocols. PTLCs have not stalled due to missing Taproot support, but due to the lack of agreement among major implementations on a shared channel update protocol. Describing the 2026 implementation status as "predictable, but slow" understates the realistic risk that Channel Factories and PTLCs may simply not arrive within any described timeframe – a perspective entirely absent from the article.El artículo presenta de forma consistentemente positiva tres extensiones de protocolo sin contextualizar los retrocesos estructurales de los últimos años: Channel Factories se debate desde 2018 — ocho años sin una implementación en producción no es casualidad, sino el reflejo de un fracaso fundamental de incentivos y coordinación inherente a los protocolos multiparte n-of-n. Los PTLCs no se han estancado por la ausencia de soporte Taproot, sino por la falta de acuerdo entre las principales implementaciones sobre un protocolo común de actualización de canales. Describir el estado de implementación en 2026 como "predecible, pero lento" subestima el riesgo realista de que Channel Factories y PTLCs sencillamente no lleguen a materializarse en ninguno de los plazos descritos — una perspectiva que brilla por su total ausencia en el artículo.O artigo apresenta de forma consistentemente positiva três extensões de protocolo, sem contextualizar os reveses estruturais dos últimos anos: Channel Factories são discutidas desde 2018 – oito anos sem uma implementação em produção não são coincidência, mas reflexo de uma falha fundamental de incentivos e coordenação inerente aos protocolos multiparticipante n-of-n. Os PTLCs não estagnou por falta de suporte ao Taproot, mas pela ausência de consenso entre as principais implementações sobre um protocolo comum de atualização de canais. Descrever o estado de implementação em 2026 como "previsível, mas lento" subestima o risco realista de que Channel Factories e PTLCs simplesmente não cheguem dentro de nenhum dos horizontes temporais descritos – uma perspectiva completamente ausente no artigo.この記事は、近年の構造的な停滞を適切に位置づけることなく、三つのプロトコル拡張を一貫して肯定的に描いている。Channel Factoriesは2018年から議論されているが、8年間にわたってプロダクション実装がゼロという事実は偶然ではなく、n-of-n マルチパーティプロトコルに固有の根本的なインセンティブ・調整の失敗を示している。PTLCsがここまで進展しなかった原因はTaprootのサポート不足ではなく、主要実装間で共通のチャネル更新プロトコルに合意できていないことにある。2026年時点の実装状況を「予測可能だが遅い」と表現するのは、Channel FactoriesとPTLCsが想定されるいかなる時間軸においても実現しないという現実的なリスクを過小評価しており、そうした視点はこの記事から完全に欠落している。该文章对三项协议扩展始终持正面态度，却未能将近年来的结构性挫折纳入背景分析：Channel Factories 自 2018 年起便已被讨论——八年来没有任何生产级实现，这绝非偶然，而是 n-of-n 多方协议在激励机制与协调层面存在根本性失败的体现。PTLCs 迄今停滞不前，并非因为缺乏 Taproot 支持，而是由于各主要实现之间无法就共同的通道更新协议达成一致。将 2026 年的实现进展描述为"可预期，只是较慢"，严重低估了一个现实风险：Channel Factories 和 PTLCs 在任何所述时间范围内根本可能不会到来——而这一视角在文中完全付之阙如。يرسم المقال صورةً إيجابيةً باستمرار لثلاثة امتدادات بروتوكولية دون أن يضع الانتكاسات الهيكلية للسنوات الأخيرة في سياقها الصحيح: فقد جرى الحديث عن Channel Factories منذ عام 2018 – وثماني سنوات دون أي تطبيق فعلي في بيئة الإنتاج ليست مجرد مصادفة، بل هي تعبير عن إخفاق جوهري في الحوافز والتنسيق المتأصل في بروتوكولات n-of-n متعددة الأطراف. ولم تتعثر PTLCs حتى الآن بسبب غياب دعم Taproot، بل بسبب عدم التوصل إلى اتفاق بين التطبيقات الكبرى على بروتوكول مشترك لتحديث القنوات. إن وصف حالة التطبيق في عام 2026 بأنها "قابلة للتخطيط لكنها بطيئة" يُقلّل من التقدير الواقعي للمخاطر بأن Channel Factories وPTLCs قد لا تظهر أبداً ضمن أي إطار زمني موصوف – وهو منظور غائب كلياً عن النص.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Das Lightning Network hat sich als Bitcoins primäres Layer-2-Zahlungsprotokoll etabliert. Doch die aktuelle Architektur stößt an strukturelle Grenzen: statische Kanalgrößen, hoher On-Chain-Footprint bei vielen Teilnehmern und eine Routing-Privatsphäre, die durch das HTLC-Preimage-Design kompromittiert werden kann. Drei Protokollerweiterungen – Splicing, Channel Factories und PTLCs – adressieren diese Schwachstellen gezielt. Alle drei bauen auf Layer-1-Primitiven auf, die mit Taproot (Block 709.632, November 2021, BIP 341) aktiviert wurden.
Splicing: Dynamische Liquidität ohne Kanalschließung
Wer heute Liquidität in einen Lightning-Kanal hinzufügt oder entnimmt, muss den Kanal schließen und neu öffnen – ein Vorgang, der zwei On-Chain-Transaktionen und Wartezeit erfordert. Splicing löst dieses UX-Problem fundamental: Es ermöglicht die dynamische Größenanpassung eines aktiven Kanals, während In-Flight-Zahlungen ungestört weiterlaufen.
Technisch wird beim Splice eine neue Funding-Transaktion on-chain veröffentlicht, die den Kanalzustand ersetzt – ohne die Off-Chain-Zahlungshistorie zu unterbrechen. Der Draft BOLT #863 beschreibt das Verfahren; Core Lightning (CLN) implementiert Splicing seit Version 23.x produktiv. Eclair (Acinq) folgte ebenfalls; die LND-Implementierung befand sich Stand 2026 noch in Entwicklung.
Phoenix Wallet (Acinq) nutzt Splicing-Mechanismen seit Version 2.x (2024) produktiv: Nutzer sehen einen einzigen dynamischen Kanal statt mehrerer statischer Kanäle – ein erheblicher UX-Fortschritt für Endanwender.
Praktisch bedeutet Splicing, dass Node-Betreiber und Endnutzer ihre Liquidität kontinuierlich optimieren können, ohne Routing-Unterbrechungen oder doppelte On-Chain-Gebühren in Kauf nehmen zu müssen.
Channel Factories: N Kanäle, eine On-Chain-Transaktion
Channel Factories, erstmals 2018 von Burchert, Decker und Wattenhofer in „Scalable Funding of Bitcoin Micropayment Channel Networks" (IEEE) formalisiert, gehen einen Schritt weiter: Sie schichten N Zahlungskanäle zwischen M Teilnehmern über eine einzige On-Chain-Funding-Transaktion. Der theoretische Gewinn ist erheblich – der On-Chain-Footprint für N Kanäle sinkt von N auf 1 Transaktion.
Die Umsetzung erfordert jedoch n-of-n-Multisig-Koordination aller Teilnehmer. Das schafft ein ungelöstes Koordinationsproblem: Jeder Teilnehmer muss saubere Exit-Mechanismen haben – bei großem N steigt die Komplexität stark an. Stand 2026 existiert keine produktive Implementierung von Channel Factories in einer der großen Lightning-Implementierungen (LND, CLN, Eclair, LDK).
Konzeptionell verwandt sind Channel Factories mit weiteren Off-Chain-Konstrukten wie Eltoo/LN-Symmetry und Ark, die ebenfalls auf Multiparty-Protokollen aufbauen. Sie gelten als vielversprechende Grundlage für zukünftige „Multiparty-Channels", sind aber noch im Forschungs- und Spezifikationsstadium.
PTLCs: Schnorr-basierte Privatsphäre statt HTLC-Preimages
HTLCs (Hash Time-Locked Contracts) sind das Herzstück des heutigen Lightning-Routings. Ihr Schwachpunkt: Das 32-Byte-SHA-256-Preimage, das zur Zahlungsabwicklung enthüllt wird, ist entlang der gesamten Route identisch. Ein passiver Beobachter, der mehrere Routing-Nodes kontrolliert, kann Zahlungen anhand dieses gemeinsamen Geheimnisses korrelieren – ein strukturelles Datenschutzproblem.
PTLCs (Point Time-Locked Contracts) ersetzen das Hash-Preimage durch Schnorr-Adaptor-Signaturen auf Basis diskreter Logarithmus-Punktpaare (secp256k1). Jeder Hop erhält ein anderes Punktpaar; das eliminiert die Payment-Korrelation durch passives Preimage-Beobachten. Gleichzeitig werden sogenannte Wormhole-Angriffe – bei denen kolludierende Nodes Zwischenhops überspringen und deren Gebühren stehlen – strukturell unterbunden.
PTLCs setzen Schnorr-Signaturen (BIP 340) und damit Taproot voraus. Zusätzlich muss die Lightning-Protokollebene MuSig2-fähige Channel-Updates unterstützen – ein koordinierter Übergang aller BOLT-Implementierungen ist erforderlich.
Der vollständige PTLC-Übergang ist die technisch anspruchsvollste der drei Erweiterungen, da er tiefe Änderungen am Channel-Update-Protokoll erfordert und rückwärtskompatibel ausgerollt werden muss. Stand 2026 laufen aktive Spezifikationsdiskussionen, eine produktive Implementierung in Mainnet-Nodes steht noch aus.
Koordination als Haupthindernis
Das Lightning Network zählt Stand Anfang 2026 rund 12.000–15.000 öffentliche Nodes und 50.000–60.000 öffentliche Kanäle (Quelle: mempool.space Lightning-Explorer). Alle drei Erweiterungen erfordern koordinierte BOLT-Anpassungen zwischen den vier großen Implementierungen LND, CLN, Eclair und LDK. Das macht den Fortschritt planbar, aber langsam: Splicing ist am weitesten gediehen, Channel Factories und PTLCs folgen mit erheblichem Abstand.
Gemeinsam würden alle drei Erweiterungen das Lightning Network transformieren: Splicing optimiert die Liquiditätsverwaltung, Channel Factories reduzieren den Block-Space-Bedarf drastisch, und PTLCs heben die Routing-Privatsphäre auf ein strukturell neues Niveau – alles auf Basis der mit Taproot bereits aktivierten kryptografischen Fundamente.
Weiterführend
The Lightning Network has established itself as Bitcoin's primary Layer-2 payment protocol. Yet the current architecture faces structural limitations: static channel sizes, high on-chain footprint when many participants are involved, and routing privacy that can be compromised by HTLC preimage design. Three protocol extensions – Splicing, Channel Factories, and PTLCs – target these weaknesses directly. All three build on Layer-1 primitives activated with Taproot (block 709,632, November 2021, BIP 341).
Splicing: Dynamic Liquidity Without Closing Channels
Today, adding or removing liquidity from a Lightning channel requires closing it and opening a new one – a process that demands two on-chain transactions and waiting time. Splicing solves this UX problem fundamentally: it enables dynamic resizing of an active channel while in-flight payments continue uninterrupted.
Technically, a splice publishes a new funding transaction on-chain that replaces the channel state – without disrupting the off-chain payment history. Draft BOLT #863 describes the procedure; Core Lightning (CLN) has implemented splicing in production since version 23.x. Eclair (Acinq) followed as well; LND's implementation was still under development as of 2026.
Phoenix Wallet (Acinq) has been using splicing mechanisms in production since version 2.x (2024): users see a single dynamic channel instead of multiple static ones – a significant UX advancement for end users.
In practice, splicing means node operators and end users can continuously optimize their liquidity without incurring routing interruptions or double on-chain fees.
Channel Factories: N Channels, One On-Chain Transaction
Channel Factories, first formalized in 2018 by Burchert, Decker, and Wattenhofer in "Scalable Funding of Bitcoin Micropayment Channel Networks" (IEEE), go a step further: they layer N payment channels among M participants over a single on-chain funding transaction. The theoretical gain is substantial – the on-chain footprint for N channels drops from N to 1 transaction.
However, implementation requires n-of-n multisig coordination among all participants. This creates an unsolved coordination problem: every participant must have clean exit mechanisms – and at large N, complexity escalates sharply. As of 2026, no production implementation of Channel Factories exists in any of the major Lightning implementations (LND, CLN, Eclair, LDK).
Conceptually, Channel Factories are related to other off-chain constructs such as Eltoo/LN-Symmetry and Ark, which also build on multiparty protocols. They are considered a promising foundation for future "multiparty channels," but remain in the research and specification stage.
PTLCs: Schnorr-Based Privacy Instead of HTLC Preimages
HTLCs (Hash Time-Locked Contracts) are the core of today's Lightning routing. Their vulnerability: the 32-byte SHA-256 preimage revealed to settle a payment is identical along the entire route. A passive observer controlling multiple routing nodes can correlate payments via this shared secret – a structural privacy problem.
PTLCs (Point Time-Locked Contracts) replace the hash preimage with Schnorr adaptor signatures based on discrete logarithm point pairs (secp256k1). Each hop receives a different point pair, eliminating payment correlation through passive preimage observation. At the same time, so-called Wormhole attacks – in which colluding nodes bypass intermediate hops and steal their fees – are structurally prevented.
PTLCs require Schnorr signatures (BIP 340) and therefore Taproot. Additionally, the Lightning protocol layer must support MuSig2-capable channel updates – a coordinated transition across all BOLT implementations is necessary.
The full PTLC transition is the most technically demanding of the three extensions, as it requires deep changes to the channel update protocol and must be deployed with backward compatibility. As of 2026, active specification discussions are ongoing; a production implementation on mainnet nodes has yet to arrive.
Coordination as the Primary Obstacle
As of early 2026, the Lightning Network counts approximately 12,000–15,000 public nodes and 50,000–60,000 public channels (source: mempool.space Lightning Explorer). All three extensions require coordinated BOLT adjustments across the four major implementations: LND, CLN, Eclair, and LDK. This makes progress predictable, but slow: Splicing is furthest along, with Channel Factories and PTLCs following at a considerable distance.
Together, all three extensions would transform the Lightning Network: Splicing optimizes liquidity management, Channel Factories drastically reduce block space requirements, and PTLCs elevate routing privacy to a structurally new level – all on the cryptographic foundation already activated by Taproot.
Related
Lightning Network se ha consolidado como el protocolo de pagos Layer-2 principal de Bitcoin. Sin embargo, la arquitectura actual se enfrenta a limitaciones estructurales: tamaños de canal estáticos, una huella on-chain elevada cuando participan muchos usuarios y una privacidad de enrutamiento que puede verse comprometida por el diseño de preimagen HTLC. Tres extensiones de protocolo – Splicing, Channel Factories y PTLCs – abordan estas debilidades de forma directa. Las tres se basan en primitivas de Layer-1 activadas con Taproot (bloque 709.632, noviembre de 2021, BIP 341).
Splicing: Liquidez dinámica sin cerrar canales
Hoy en día, añadir o retirar liquidez de un canal Lightning obliga a cerrarlo y abrirlo de nuevo, un proceso que requiere dos transacciones on-chain y tiempo de espera. Splicing resuelve este problema de UX de raíz: permite redimensionar dinámicamente un canal activo mientras los pagos en tránsito continúan sin interrupciones.
Técnicamente, un splice publica on-chain una nueva transacción de financiación que reemplaza el estado del canal sin interrumpir el historial de pagos off-chain. El borrador BOLT #863 describe el procedimiento; Core Lightning (CLN) implementa Splicing en producción desde la versión 23.x. Eclair (Acinq) también lo incorporó; la implementación de LND estaba aún en desarrollo a fecha de 2026.
Phoenix Wallet (Acinq) utiliza mecanismos de Splicing en producción desde la versión 2.x (2024): los usuarios ven un único canal dinámico en lugar de varios canales estáticos, lo que supone un avance significativo de UX para los usuarios finales.
En la práctica, Splicing significa que los operadores de nodos y los usuarios finales pueden optimizar su liquidez de forma continua sin asumir interrupciones de enrutamiento ni pagar dobles comisiones on-chain.
Channel Factories: N canales, una sola transacción on-chain
Las Channel Factories, formalizadas por primera vez en 2018 por Burchert, Decker y Wattenhofer en «Scalable Funding of Bitcoin Micropayment Channel Networks» (IEEE), van un paso más allá: agrupan N canales de pago entre M participantes sobre una única transacción de financiación on-chain. La ganancia teórica es considerable: la huella on-chain para N canales se reduce de N a 1 transacción.
Sin embargo, la implementación requiere coordinación multisig n-de-n entre todos los participantes, lo que genera un problema de coordinación sin resolver: cada participante debe disponer de mecanismos de salida limpios, y la complejidad crece significativamente con N grande. A fecha de 2026, ninguna de las principales implementaciones de Lightning (LND, CLN, Eclair, LDK) cuenta con una implementación productiva de Channel Factories.
Conceptualmente, las Channel Factories guardan relación con otras construcciones off-chain como Eltoo/LN-Symmetry y Ark, que también se basan en protocolos multipartitos. Se consideran una base prometedora para futuros «canales multipartitos», aunque siguen en fase de investigación y especificación.
PTLCs: Privacidad basada en Schnorr en lugar de preimágenes HTLC
Los HTLCs (Hash Time-Locked Contracts) son el núcleo del enrutamiento Lightning actual. Su punto débil: la preimagen SHA-256 de 32 bytes que se revela para liquidar un pago es idéntica a lo largo de toda la ruta. Un observador pasivo que controle varios nodos de enrutamiento puede correlacionar pagos a través de este secreto compartido, lo que constituye un problema estructural de privacidad.
Los PTLCs (Point Time-Locked Contracts) sustituyen la preimagen hash por firmas adaptadoras Schnorr basadas en pares de puntos de logaritmo discreto (secp256k1). Cada salto recibe un par de puntos distinto, lo que elimina la correlación de pagos mediante la observación pasiva de preimágenes. Al mismo tiempo, se previenen de forma estructural los denominados ataques Wormhole, en los que nodos coludidos se saltan saltos intermedios y roban sus comisiones.
Los PTLCs requieren firmas Schnorr (BIP 340) y, por tanto, Taproot. Además, la capa del protocolo Lightning debe soportar actualizaciones de canal compatibles con MuSig2, lo que exige una transición coordinada en todas las implementaciones BOLT.
La transición completa a PTLCs es la más exigente técnicamente de las tres extensiones, ya que requiere cambios profundos en el protocolo de actualización de canal y debe desplegarse manteniendo compatibilidad con versiones anteriores. A fecha de 2026, los debates de especificación siguen activos y aún no existe una implementación productiva en nodos de mainnet.
La coordinación como principal obstáculo
A principios de 2026, Lightning Network contaba con aproximadamente 12.000–15.000 nodos públicos y 50.000–60.000 canales públicos (fuente: mempool.space Lightning Explorer). Las tres extensiones requieren ajustes coordinados de los BOLT entre las cuatro implementaciones principales: LND, CLN, Eclair y LDK. Esto hace que el avance sea predecible, aunque lento: Splicing es la que más ha progresado, mientras que Channel Factories y PTLCs le siguen a una distancia considerable.
Juntas, las tres extensiones transformarían Lightning Network: Splicing optimiza la gestión de liquidez, Channel Factories reduce drásticamente el consumo de espacio en bloques y PTLCs eleva la privacidad del enrutamiento a un nivel estructuralmente nuevo, todo ello sobre los fundamentos criptográficos ya activados por Taproot.
Más información
O Lightning Network estabeleceu-se como o principal protocolo de pagamento de Layer 2 do Bitcoin. No entanto, a arquitetura atual esbarra em limitações estruturais: tamanhos de canais estáticos, elevada pegada on-chain com muitos participantes e uma privacidade de roteamento que pode ser comprometida pelo design do HTLC preimage. Três extensões de protocolo – Splicing, Channel Factories e PTLCs – abordam estas vulnerabilidades de forma direcionada. As três assentam em primitivas de Layer 1 ativadas com o Taproot (bloco 709.632, novembro de 2021, BIP 341).
Splicing: Liquidez dinâmica sem encerramento de canal
Quem hoje pretende adicionar ou retirar liquidez de um canal Lightning tem de fechar o canal e reabri-lo — um processo que exige duas transações on-chain e tempo de espera. O Splicing resolve este problema de UX de forma fundamental: permite o redimensionamento dinâmico de um canal ativo enquanto os pagamentos in-flight continuam sem interrupção.
Do ponto de vista técnico, num splice é publicada on-chain uma nova transação de financiamento que substitui o estado do canal — sem interromper o histórico de pagamentos off-chain. O Draft BOLT #863 descreve o procedimento; o Core Lightning (CLN) implementa o Splicing em produção desde a versão 23.x. O Eclair (Acinq) seguiu o mesmo caminho; a implementação no LND encontrava-se ainda em desenvolvimento em 2026.
A Phoenix Wallet (Acinq) utiliza mecanismos de Splicing em produção desde a versão 2.x (2024): os utilizadores veem um único canal dinâmico em vez de vários canais estáticos — um avanço significativo de UX para os utilizadores finais.
Na prática, o Splicing significa que operadores de nós e utilizadores finais podem otimizar continuamente a sua liquidez sem terem de aceitar interrupções de roteamento ou pagar taxas on-chain duplicadas.
Channel Factories: N canais, uma transação on-chain
Channel Factories, formalizadas pela primeira vez em 2018 por Burchert, Decker e Wattenhofer em "Scalable Funding of Bitcoin Micropayment Channel Networks" (IEEE), vão um passo mais longe: empilham N canais de pagamento entre M participantes sobre uma única transação de financiamento on-chain. O ganho teórico é considerável — o footprint on-chain para N canais desce de N para 1 transação.
A implementação exige, no entanto, coordenação multisig n-of-n de todos os participantes. Isso cria um problema de coordenação por resolver: cada participante precisa de mecanismos de saída limpos — com um N elevado, a complexidade aumenta significativamente. Em 2026, não existe nenhuma implementação em produção de Channel Factories em nenhuma das principais implementações Lightning (LND, CLN, Eclair, LDK).
Do ponto de vista conceptual, as Channel Factories estão relacionadas com outras construções off-chain como Eltoo/LN-Symmetry e Ark, que também assentam em protocolos multiparty. São consideradas uma base promissora para futuros "Multiparty-Channels", mas encontram-se ainda na fase de investigação e especificação.
PTLCs: privacidade baseada em Schnorr em vez de preimages HTLC
Os HTLCs (Hash Time-Locked Contracts) são o coração do routing Lightning atual. O seu ponto fraco: o preimage SHA-256 de 32 bytes, revelado para liquidar o pagamento, é idêntico ao longo de toda a rota. Um observador passivo que controle vários nós de routing pode correlacionar pagamentos com base neste segredo partilhado — um problema estrutural de privacidade.
Os PTLCs (Point Time-Locked Contracts) substituem o preimage de hash por assinaturas Schnorr adaptor baseadas em pares de pontos de logaritmo discreto (secp256k1). Cada hop recebe um par de pontos diferente, o que elimina a correlação de pagamentos através da observação passiva de preimages. Ao mesmo tempo, os chamados ataques Wormhole — nos quais nós conluiados ignoram hops intermédios e roubam as respetivas comissões — são estruturalmente impedidos.
Os PTLCs requerem assinaturas Schnorr (BIP 340) e, por conseguinte, Taproot. Além disso, a camada do protocolo Lightning tem de suportar atualizações de canais compatíveis com MuSig2 — sendo necessária uma transição coordenada de todas as implementações BOLT.
A transição completa para PTLCs é a mais exigente tecnicamente das três extensões, pois requer alterações profundas no protocolo de atualização de canais e tem de ser implementada de forma retrocompatível. Em 2026, decorrem discussões de especificação ativas, e uma implementação em produção em nós da mainnet ainda não existe.
A coordenação como principal obstáculo
A Lightning Network conta, no início de 2026, com cerca de 12.000–15.000 nós públicos e 50.000–60.000 canais públicos (fonte: Lightning Explorer do mempool.space). As três extensões exigem adaptações coordenadas do BOLT entre as quatro grandes implementações LND, CLN, Eclair e LDK. Isso torna o progresso previsível, mas lento: o Splicing é o que está mais avançado, seguido a distância considerável pelas Channel Factories e pelos PTLCs.
Em conjunto, as três extensões transformariam a Lightning Network: o Splicing otimiza a gestão de liquidez, as Channel Factories reduzem drasticamente a necessidade de espaço em bloco, e os PTLCs elevam a privacidade no roteamento a um nível estruturalmente novo — tudo com base nos fundamentos criptográficos já ativados com o Taproot.
Mais informação
Lightning Networkは、BitcoinのプライマリLayer-2決済プロトコルとして確固たる地位を築いています。しかし現在のアーキテクチャには構造的な限界があります。チャネルサイズが静的であること、参加者が多い場合のオンチェーンフットプリントが大きいこと、そしてHTLCプリイメージ設計によってルーティングのプライバシーが損なわれる可能性があることです。Splicing、Channel Factories、PTLCsという3つのプロトコル拡張が、これらの弱点に直接対処します。いずれもTaproot（ブロック709,632、2021年11月、BIP 341）で有効化されたLayer-1プリミティブを基盤としています。
Splicing：チャネルを閉じずに実現する動的な流動性
現在、Lightningチャネルへの流動性の追加や引き出しには、チャネルを一度閉鎖して新たに開設し直す必要があります。このプロセスには2回のオンチェーントランザクションと待機時間が伴います。Splicingはこのユーザー体験上の問題を根本的に解決します。インフライト中の支払いを中断することなく、アクティブなチャネルのサイズを動的に変更できるようになります。
技術的には、Spliceの際に新たなファンディングトランザクションがオンチェーンに公開され、オフチェーンの支払い履歴を中断することなくチャネル状態が更新されます。Draft BOLT #863がその手順を定義しており、Core Lightning（CLN）はバージョン23.x以降、本番環境でSplicingを実装しています。Eclair（Acinq）も同様に対応済みで、LNDの実装は2026年時点では開発中でした。
Phoenix Wallet（Acinq）は、バージョン2.x（2024年）以降、本番環境でSplicingの仕組みを活用しています。ユーザーには複数の静的チャネルではなく、単一の動的チャネルが表示されます。これはエンドユーザーにとって大きなユーザー体験の向上です。
実用面では、Splicingによってノード運営者およびエンドユーザーは、ルーティングの中断やオンチェーン手数料の二重負担を生じさせることなく、継続的に流動性を最適化できます。
Channel Factories：Nチャネルを1回のオンチェーントランザクションで
Channel Factoriesは、2018年にBurchert、Decker、Wattenhoferによって「Scalable Funding of Bitcoin Micropayment Channel Networks」（IEEE）で初めて体系化されたもので、さらに一歩進んだアプローチをとります。M人の参加者間にN本の決済チャネルを、単一のオンチェーンファンディングトランザクション上に重ねて構築します。理論上の利点は大きく、Nチャネル分のオンチェーンフットプリントをN件から1件のトランザクションに削減できます。
ただし実装には、全参加者によるn-of-nマルチシグの協調が必要です。これにより未解決の協調問題が生じます。各参加者がクリーンな退出手段を持たなければならず、Nが大きくなるほど複雑性が急激に増大します。2026年時点では、主要なLightning実装（LND、CLN、Eclair、LDK）のいずれにも、Channel Factoriesの本番実装は存在しません。
概念的には、Channel FactoriesはEltoo/LN-SymmetryやArkなど、同様にマルチパーティプロトコルを基盤とする他のオフチェーン構造とも関連しています。将来の「マルチパーティチャネル」への有望な基盤として評価されていますが、依然として研究・仕様策定の段階にあります。
PTLCs：HTLCプリイメージに代わるSchnorrベースのプライバシー
HTLC（Hash Time-Locked Contracts）は、現在のLightningルーティングの中核をなしています。その弱点は、支払いの決済に際して開示される32バイトのSHA-256プリイメージがルート全体で同一である点です。複数のルーティングノードを制御する受動的な観察者は、この共有シークレットを用いて支払いを相関付けることができ、これは構造的なプライバシー問題です。
PTLC（Point Time-Locked Contracts）は、ハッシュプリイメージを離散対数点ペア（secp256k1）に基づくSchnorrアダプター署名に置き換えます。各ホップは異なる点ペアを受け取るため、受動的なプリイメージ観察による支払いの相関付けが排除されます。同時に、共謀するノードが中間ホップをスキップしてその手数料を奪う、いわゆるワームホール攻撃も構造的に防止されます。
PTLCsにはSchnorr署名（BIP 340）、すなわちTaprootが必要です。さらに、LightningプロトコルレイヤーがMuSig2対応のチャネル更新をサポートする必要があり、すべてのBOLT実装にわたる協調的な移行が求められます。
PTLCへの完全移行は、3つの拡張の中で技術的に最も難易度が高いものです。チャネル更新プロトコルへの深い変更が必要であり、後方互換性を保ちながら展開しなければなりません。2026年時点では活発な仕様策定の議論が続いており、メインネットノードへの本番実装はまだ実現していません。
協調こそが最大の障壁
2026年初頭時点で、Lightning Networkには約12,000〜15,000のパブリックノードと50,000〜60,000のパブリックチャネルが存在します（出典：mempool.space Lightning Explorer）。3つの拡張すべてにおいて、LND、CLN、Eclair、LDKという4つの主要実装間での協調的なBOLT調整が必要です。これにより進捗は予測可能ではあるものの、緩やかなものとなります。Splicingが最も進んでおり、Channel FactoriesとPTLCsはかなりの差をつけて後に続いています。
3つの拡張が揃えば、Lightning Networkは大きく変わります。Splicingが流動性管理を最適化し、Channel Factoriesがブロックスペースの需要を大幅に削減し、PTLCsがルーティングのプライバシーを構造的に新たな水準へと引き上げます。そのすべてが、Taprootによってすでに有効化された暗号技術的基盤の上に成り立っています。
関連情報
Lightning Network 已确立为 Bitcoin 的主要二层支付协议。然而，当前架构面临结构性局限：静态通道容量、大量参与者带来的高链上占用，以及因 HTLC 原像设计而可能遭到破坏的路由隐私。三项协议扩展——Splicing、Channel Factories 与 PTLCs——正是针对这些弱点的定向解决方案。三者均建立在 Taproot（区块 709,632，2021 年 11 月，BIP 341）激活的一层原语之上。
Splicing：无需关闭通道的动态流动性管理
如今，向 Lightning 通道增减流动性，需要先关闭通道再重新开启——整个流程需要两笔链上交易和相应的等待时间。Splicing 从根本上解决了这一用户体验问题：它允许在活跃通道运行期间动态调整通道容量，而飞行中的支付不受任何影响。
技术层面，Splicing 会在链上发布一笔新的资金交易以替换通道状态，同时不中断链下的支付历史。Draft BOLT #863 描述了该流程；Core Lightning（CLN）自 23.x 版本起已在生产环境中实现 Splicing。Eclair（Acinq）随后也跟进了该功能；截至 2026 年，LND 的实现仍在开发中。
Phoenix Wallet（Acinq）自 2.x 版本（2024 年）起已在生产环境中使用 Splicing 机制：用户看到的是单一的动态通道，而非多个静态通道——对终端用户而言，这是显著的用户体验提升。
在实践中，Splicing 意味着节点运营者和终端用户可以持续优化自身流动性，无需承受路由中断或双重链上手续费的代价。
Channel Factories：N 条通道，一笔链上交易
Channel Factories 由 Burchert、Decker 与 Wattenhofer 于 2018 年在 "Scalable Funding of Bitcoin Micropayment Channel Networks"（IEEE）中首次正式提出，其思路更进一步：通过单笔链上资金交易，在 M 个参与者之间叠加 N 条支付通道。理论收益相当可观——N 条通道的链上占用从 N 笔交易降至 1 笔。
然而，实现这一方案需要所有参与者进行 n-of-n 多签协调，由此产生了一个尚未解决的协调难题：每位参与者都必须拥有可靠的退出机制——当 N 较大时，复杂度会急剧攀升。截至 2026 年，各大 Lightning 实现（LND、CLN、Eclair、LDK）中均不存在 Channel Factories 的生产级实现。
从概念上看，Channel Factories 与 Eltoo/LN-Symmetry、Ark 等其他链下构造有所关联，后者同样建立在多方协议之上。它们被视为未来"多方通道"的有前景的基础，但目前仍处于研究与规范阶段。
PTLCs：基于 Schnorr 的隐私方案，取代 HTLC 原像
HTLCs（哈希时间锁定合约）是当今 Lightning 路由的核心。其弱点在于：用于完成支付而披露的 32 字节 SHA-256 原像在整条路由上完全相同。控制多个路由节点的被动观察者可通过这一共享秘密关联不同支付——这是一个结构性隐私问题。
PTLCs（点时间锁定合约）以基于离散对数点对（secp256k1）的 Schnorr 适配器签名取代哈希原像。每一跳获得不同的点对，从而消除了通过被动观察原像进行支付关联的可能性。与此同时，所谓的虫洞攻击——即串谋节点绕过中间跳并窃取其手续费——也在结构层面得到了根本性遏制。
PTLCs 需要 Schnorr 签名（BIP 340），因而依赖 Taproot。此外，Lightning 协议层还必须支持兼容 MuSig2 的通道更新——这需要所有 BOLT 实现协调一致地完成过渡。
完整的 PTLC 过渡是三项扩展中技术难度最高的，因为它需要对通道更新协议进行深层改动，并且必须以向后兼容的方式部署。截至 2026 年，相关规范讨论仍在积极推进中，主网节点的生产级实现尚未落地。
协调是最大障碍
截至 2026 年初，Lightning Network 拥有约 12,000 至 15,000 个公开节点和 50,000 至 60,000 条公开通道（数据来源：mempool.space Lightning Explorer）。三项扩展均需要 LND、CLN、Eclair 和 LDK 四大实现之间协调完成 BOLT 调整。这使得进展可预期，但步伐较慢：Splicing 推进最为成熟，Channel Factories 与 PTLCs 则相差甚远。
若三项扩展共同落地，将彻底变革 Lightning Network：Splicing 优化流动性管理，Channel Factories 大幅降低区块空间需求，PTLCs 则将路由隐私提升至结构性新高度——所有这些均建立在 Taproot 已激活的密码学基础之上。
延伸阅读
أرسى شبكة Lightning مكانتها بوصفها بروتوكول الدفع الأساسي من الطبقة الثانية لـ Bitcoin. غير أن البنية الحالية تصطدم بقيود هيكلية: أحجام قنوات ثابتة، وبصمة كبيرة على السلسلة الرئيسية عند تزايد عدد المشاركين، فضلاً عن خصوصية التوجيه التي قد يُعرّضها تصميم HTLC Preimage للخطر. ثلاثة امتدادات بروتوكولية — Splicing, Channel Factories و PTLCs — تعالج هذه الثغرات بشكل مباشر. وتستند الثلاثة جميعها إلى آليات الطبقة الأولى التي أتاحها تفعيل Taproot (الكتلة 709,632، نوفمبر 2021، BIP 341).
Splicing: سيولة ديناميكية دون إغلاق القناة
من يريد اليوم إضافة سيولة إلى قناة Lightning أو سحبها منها، فعليه إغلاق القناة وإعادة فتحها — وهي عملية تستلزم معاملتين على السلسلة الرئيسية ووقت انتظار. يحلّ Splicing هذه المشكلة على مستوى تجربة المستخدم حلاً جذرياً: إذ يتيح تعديل حجم القناة النشطة ديناميكياً، بينما تواصل المدفوعات الجارية سيرها دون انقطاع.
من الناحية التقنية، تُنشر عند إجراء Splice معاملة تمويل جديدة على السلسلة الرئيسية تحلّ محل حالة القناة، دون أن تُعطّل سجل المدفوعات خارج السلسلة. يصف Draft BOLT #863 هذا الإجراء بالتفصيل؛ وقد طبّق Core Lightning (CLN)) آلية Splicing في بيئة الإنتاج منذ الإصدار 23.x. وتبعه Eclair (Acinq) في ذلك، فيما كان تطبيق LND لا يزال قيد التطوير حتى عام 2026.
تستخدم Phoenix Wallet (Acinq) آليات Splicing في بيئة الإنتاج منذ الإصدار 2.x (2024): يرى المستخدمون قناة واحدة ديناميكية بدلاً من قنوات ثابتة متعددة — وهو تقدم ملموس في تجربة المستخدم للمستخدمين النهائيين.
عملياً، يعني Splicing أن مشغّلي العقد والمستخدمين النهائيين يستطيعون تحسين سيولتهم باستمرار، دون الاضطرار إلى تحمّل انقطاعات في التوجيه أو دفع رسوم مضاعفة على السلسلة الرئيسية.
Channel Factories: N قناة في معاملة واحدة على السلسلة الرئيسية
مصانع القنوات (Channel Factories)، التي وثّقها لأول مرة عام 2018 كلٌّ من Burchert وDecker وWattenhofer في "Scalable Funding of Bitcoin Micropayment Channel Networks" (IEEE)، تذهب خطوةً أبعد من ذلك: إذ تُراكم N قناةً للدفع بين M مشاركاً فوق معاملة تمويل واحدة على السلسلة (On-Chain). والمكسب النظري كبير — إذ ينخفض البصمة على السلسلة لـ N قناة من N معاملة إلى معاملة واحدة فقط.
غير أن التنفيذ يستلزم تنسيق توقيع متعدد n-of-n بين جميع المشاركين، مما يُفرز مشكلة تنسيق لم تُحَل بعد: فكل مشارك يجب أن يمتلك آليات خروج نظيفة، وكلما كبُر N ازداد التعقيد بشكل حاد. حتى عام 2026، لا توجد أي تطبيق إنتاجي لمصانع القنوات في أيٍّ من كبريات تطبيقات Lightning (LND وCLN وEclair وLDK).
تتقاطع مصانع القنوات مفاهيمياً مع بنى أخرى خارج السلسلة (Off-Chain) كـ Eltoo/LN-Symmetry وArk، التي تقوم هي الأخرى على بروتوكولات متعددة الأطراف. وتُعدّ أساساً واعداً لـ"قنوات متعددة الأطراف" مستقبلية، إلا أنها لا تزال في طور البحث ووضع المواصفات.
PTLCs: الخصوصية المستندة إلى Schnorr بدلاً من HTLC Preimages
تُشكّل HTLCs (Hash Time-Locked Contracts) جوهر توجيه Lightning اليوم. ونقطة ضعفها أن الـ Preimage المؤلّف من 32 بايت بخوارزمية SHA-256، الذي يُكشف عند تسوية الدفعة، يكون متطابقاً على طول المسار بأكمله. ومن ثَمّ يستطيع مراقب سلبي يتحكم في عدة عُقَد توجيه أن يربط بين المدفوعات استناداً إلى هذا السر المشترك — وهو إشكالية هيكلية تتعلق بالخصوصية.
تستبدل PTLCs (Point Time-Locked Contracts) الـ Hash Preimage بتوقيعات Schnorr Adaptor المبنية على أزواج نقاط اللوغاريتم المنفصل (secp256k1). ويحصل كل hop على زوج نقاط مختلف، مما يُلغي إمكانية ربط المدفوعات عبر مراقبة الـ Preimage بشكل سلبي. وفي الوقت ذاته، يُعيق هذا النهج هيكلياً ما يُعرف بـ هجمات الدودة (Wormhole Attacks) — وهي الهجمات التي تتخطى فيها العُقَد المتواطئة الـ Hops الوسيطة وتسرق رسومها.
تستلزم PTLCs توقيعات Schnorr (BIP 340) وبالتالي Taproot. علاوةً على ذلك، يجب أن تدعم طبقة بروتوكول Lightning تحديثات القنوات المتوافقة مع MuSig2 — وهو ما يستوجب انتقالاً منسّقاً لجميع تطبيقات BOLT.
يُعدّ الانتقال الكامل إلى PTLC الأكثر تعقيداً تقنياً بين الإضافات الثلاث، إذ يتطلب تعديلات عميقة على بروتوكول تحديث القناة ويجب طرحه بشكل متوافق مع الإصدارات السابقة. حتى عام 2026، تجري نقاشات مواصفات نشطة، في حين لا يزال التطبيق الإنتاجي في عُقَد الشبكة الرئيسية (Mainnet) غائباً.
التنسيق باعتباره العقبة الرئيسية
يضم شبكة Lightning حتى مطلع عام 2026 نحو 12,000 إلى 15,000 عقدة عامة و50,000 إلى 60,000 قناة عامة (المصدر: مستكشف Lightning على mempool.space). وتستلزم الإضافات الثلاث جميعها تعديلات منسّقة على مواصفات BOLT بين التطبيقات الأربعة الكبرى: LND وCLN وEclair وLDK. وهذا يجعل التقدم قابلاً للتخطيط، غير أنه بطيء: فـSplicing هو الأكثر تقدماً حتى الآن، في حين تتأخر Channel Factories وPTLCs بفارق ملحوظ.
ستُحوِّل هذه الإضافات الثلاث مجتمعةً شبكة Lightning تحويلاً جذرياً: إذ يُحسِّن Splicing إدارة السيولة، وتُقلِّص Channel Factories الحاجة إلى مساحة الكتلة تقليصاً حاداً، بينما ترفع PTLCs خصوصية التوجيه إلى مستوى هيكلي جديد — وكل ذلك على أساس الركائز التشفيرية التي فعّلها Taproot بالفعل.
مزيد من المعلومات
⚖️ Die stärksten GegenargumenteThe Strongest CounterargumentsLos contraargumentos más fuertesOs contra-argumentos mais fortes最も強力な反論最有力的反方观点أقوى الحجج المضادة
Jedes Gegenargument in seiner stärksten Form – geprüft und nach Datenlage entschieden, kein Wunschdenken.Each counterargument in its strongest form – scrutinized and adjudicated per the data, no wishful thinking.Cada contraargumento en su forma más fuerte: examinado y juzgado según los datos, sin ilusiones.Cada contra-argumento na sua forma mais forte – examinado e julgado segundo os dados, sem ilusões.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
Channel Factories kommen womöglich nie: Acht Jahre ohne produktive Implementierung seit dem Paper von 2018 deuten auf fundamentale Hürden – n-of-n-Koordination und fehlende Layer-1-Primitiven wie ein aktivierter Covenant-Mechanismus (SIGHASH_ANYPREVOUT/Eltoo) – und nicht auf bloße Langsamkeit.Channel factories may never arrive: eight years without a production implementation since the 2018 paper point to fundamental barriers — n-of-n coordination and missing Layer-1 primitives such as an activated covenant mechanism (SIGHASH_ANYPREVOUT/Eltoo) — not mere slowness.Las channel factories quizá nunca lleguen: ocho años sin una implementación productiva desde el artículo de 2018 apuntan a barreras fundamentales — la coordinación n-de-n y la falta de primitivas de capa 1 activadas, como un mecanismo de covenant (SIGHASH_ANYPREVOUT/Eltoo) — y no a mera lentitud.As channel factories talvez nunca cheguem: oito anos sem implementação produtiva desde o paper de 2018 apontam para barreiras fundamentais — coordenação n-de-n e a falta de primitivas de camada 1 ativadas, como um mecanismo de covenant (SIGHASH_ANYPREVOUT/Eltoo) — e não para mera lentidão.Channel Factoriesは永遠に実現しない可能性がある。2018年の論文から8年間、本番実装が一つも存在しないのは、単なる開発の遅れではなく、n-of-n協調や、有効化されていないレイヤー1のプリミティブ(SIGHASH_ANYPREVOUT/Eltooのようなコベナント機構)という根本的な障壁を示唆している。Channel Factories可能永远不会落地:自2018年论文发表以来8年没有任何生产级实现,指向的是根本性障碍——n-of-n多方协调难题,以及尚未激活的一层原语(如SIGHASH_ANYPREVOUT/Eltoo这类covenant机制)——而不是单纯的进度缓慢。قد لا ترى Channel Factories النور أبدا: فثماني سنوات دون أي تنفيذ إنتاجي منذ ورقة 2018 تشير إلى عوائق جوهرية — تنسيق n-of-n وغياب أساسيات الطبقة الأولى المفعلة مثل آلية covenant من نوع SIGHASH_ANYPREVOUT/Eltoo — لا إلى مجرد بطء.
Belegt: Der Artikel bestätigt selbst, dass 2026 keine der vier großen Implementierungen (LND, CLN, Eclair, LDK) Channel Factories produktiv unterstützt und verwandte Konstrukte (Eltoo/LN-Symmetry) im Forschungsstadium stecken; der dafür diskutierte Soft Fork ist nicht aktiviert. Die Transformations-Erzählung bleibt insoweit Spekulation.Substantiated: the article itself confirms that as of 2026 none of the four major implementations (LND, CLN, Eclair, LDK) supports channel factories in production and that related constructs (Eltoo/LN-Symmetry) remain research-stage; the soft fork discussed for them is not activated. To that extent, the transformation narrative stays speculative.Confirmado: el propio artículo reconoce que en 2026 ninguna de las cuatro grandes implementaciones (LND, CLN, Eclair, LDK) soporta channel factories en producción y que los constructos relacionados (Eltoo/LN-Symmetry) siguen en fase de investigación; el soft fork discutido para ello no está activado. En esa medida, la narrativa de transformación sigue siendo especulativa.Confirmado: o próprio artigo reconhece que, em 2026, nenhuma das quatro grandes implementações (LND, CLN, Eclair, LDK) suporta channel factories em produção e que construtos relacionados (Eltoo/LN-Symmetry) seguem em fase de pesquisa; o soft fork discutido para isso não foi ativado. Nessa medida, a narrativa de transformação permanece especulativa.立証済み:2026年時点で主要4実装(LND、CLN、Eclair、LDK)のいずれもChannel Factoriesを本番運用しておらず、関連構想(Eltoo/LN-Symmetry)が研究段階にあることは記事自身が認めている。必要とされるソフトフォークも有効化されていない。その限りで「変革」の物語は推測にとどまる。成立:文章自己承认,截至2026年四大实现(LND、CLN、Eclair、LDK)均未在生产环境支持Channel Factories,相关构想(Eltoo/LN-Symmetry)仍处于研究阶段;为此讨论的软分叉也未激活。就此而言,「变革」叙事仍属推测。مثبت: يؤكد المقال نفسه أنه حتى 2026 لا يدعم أي من التنفيذات الأربعة الكبرى (LND وCLN وEclair وLDK) هذه التقنية إنتاجيا، وأن البنى ذات الصلة (Eltoo/LN-Symmetry) ما زالت في طور البحث؛ كما أن الانقسام الناعم المطلوب لم يفعل. وبذلك تبقى سردية التحول تكهنا.
Die PTLC-Verzögerung ist ein Koordinationsversagen, kein Technikproblem: Taproot ist seit November 2021 (Block 709.632) aktiv, doch über vier Jahre später existiert keine Mainnet-Implementierung – der Übergang kann sich unbegrenzt weiter verzögern.The PTLC delay is a coordination failure, not a technology problem: Taproot has been active since November 2021 (block 709,632), yet more than four years later no mainnet implementation exists — the transition can keep slipping indefinitely.El retraso de los PTLC es un fallo de coordinación, no un problema técnico: Taproot está activo desde noviembre de 2021 (bloque 709.632) y, más de cuatro años después, no existe una implementación en mainnet; la transición puede seguir aplazándose indefinidamente.O atraso dos PTLCs é uma falha de coordenação, não um problema técnico: o Taproot está ativo desde novembro de 2021 (bloco 709.632) e, mais de quatro anos depois, não existe implementação em mainnet — a transição pode continuar adiada indefinidamente.PTLCの遅れは技術の問題ではなく、協調の失敗である。Taprootは2021年11月(ブロック709,632)から有効だが、4年以上経ってもメインネット実装は存在しない。移行は際限なく先送りされうる。PTLC的延迟是协调失败,而非技术问题:Taproot自2021年11月(区块709,632)起已激活,但4年多过去仍无主网实现——这一过渡可能被无限期推迟。تأخر PTLC فشل في التنسيق لا مشكلة تقنية: فقد فعل Taproot منذ نوفمبر 2021 (الكتلة 709,632)، ومع ذلك لا يوجد تنفيذ على الشبكة الرئيسية بعد أكثر من أربع سنوات — وقد يستمر تأجيل الانتقال إلى أجل غير مسمى.
Belegt: Die kryptografischen Voraussetzungen (BIP 340/341) liegen seit 2021 vor; der Artikel selbst verortet PTLCs 2026 weiter im Spezifikationsstadium. Die Datenlage stützt den Einwand, dass nicht die Technik, sondern die implementierungsübergreifende Einigung der Engpass ist – mit offenem Zeithorizont.Substantiated: the cryptographic prerequisites (BIP 340/341) have been in place since 2021; the article itself places PTLCs at the specification-discussion stage in 2026. The data supports the objection that the bottleneck is cross-implementation agreement, not technology — with an open-ended timeline.Confirmado: los requisitos criptográficos (BIP 340/341) existen desde 2021; el propio artículo sitúa los PTLC en fase de discusión de especificación en 2026. Los datos respaldan la objeción de que el cuello de botella es el acuerdo entre implementaciones, no la tecnología — con un horizonte temporal abierto.Confirmado: os pré-requisitos criptográficos (BIP 340/341) existem desde 2021; o próprio artigo situa os PTLCs em fase de discussão de especificação em 2026. Os dados sustentam a objeção de que o gargalo é o acordo entre implementações, não a tecnologia — com horizonte temporal em aberto.立証済み:暗号学的な前提条件(BIP 340/341)は2021年から整っており、記事自身も2026年時点のPTLCを仕様検討段階と位置づけている。ボトルネックが技術ではなく実装間合意であるという異論をデータが裏づけており、時間軸は不確定である。成立:密码学前提(BIP 340/341)自2021年即已具备;文章自己也将2026年的PTLC定位在规范讨论阶段。数据支持这一异议:瓶颈在于各实现之间的协调一致,而非技术本身——时间表完全开放。مثبت: المتطلبات التشفيرية (BIP 340/341) متوفرة منذ 2021؛ والمقال نفسه يضع PTLC في مرحلة نقاش المواصفات عام 2026. تدعم المعطيات الاعتراض بأن عنق الزجاجة هو التوافق بين التنفيذات لا التقنية — والأفق الزمني مفتوح.
Selbst bei vollständiger Umsetzung ändern die drei Erweiterungen womöglich wenig am Kurs des Netzwerks: Sie adressieren Effizienz und Privatsphäre, nicht aber die Onboarding-Kosten für Inbound-Liquidität und nicht den beobachtbaren Drift der Nutzer zu custodialen Lösungen.Even fully deployed, the three extensions may change little about the network's trajectory: they address efficiency and privacy, but not the onboarding cost of inbound liquidity and not the observable drift of users toward custodial solutions.Incluso desplegadas por completo, las tres extensiones quizá cambien poco la trayectoria de la red: abordan eficiencia y privacidad, pero no el coste de incorporación de liquidez entrante ni la deriva observable de los usuarios hacia soluciones custodiales.Mesmo totalmente implantadas, as três extensões talvez mudem pouco a trajetória da rede: elas tratam de eficiência e privacidade, mas não do custo de onboarding de liquidez de entrada nem da migração observável dos usuários para soluções custodiais.たとえ完全に実装されても、3つの拡張はネットワークの軌道をほとんど変えないかもしれない。これらは効率とプライバシーに対処するが、インバウンド流動性のオンボーディングコストや、ユーザーがカストディアル型サービスへ流れる観察可能な傾向には対処しない。即使全部落地,这三项扩展也未必能改变网络的走向:它们解决的是效率与隐私,而不是入站流动性的准入成本,也不是用户明显流向托管方案的趋势。حتى مع التنفيذ الكامل، قد لا تغير التوسعات الثلاث مسار الشبكة كثيرا: فهي تعالج الكفاءة والخصوصية، لكنها لا تعالج كلفة تأمين السيولة الواردة للمستخدمين الجدد ولا الانجراف الملحوظ نحو الحلول الوصائية.
Offen: Der Trend zu custodialer bzw. LSP-vermittelter Nutzung ist beobachtbar, doch ob Protokoll-Upgrades ihn bremsen oder umkehren würden, lässt sich aus der heutigen Datenlage nicht seriös beurteilen. Wirkungsprognosen in beide Richtungen wären Spekulation.Open: the drift toward custodial and LSP-mediated usage is observable, but whether protocol upgrades would slow or reverse it cannot be seriously judged from today's data. Impact forecasts in either direction would be speculation.Abierto: la deriva hacia el uso custodial o mediado por LSP es observable, pero con los datos actuales no puede juzgarse con seriedad si las mejoras de protocolo la frenarían o revertirían. Pronosticar el impacto en cualquier dirección sería especular.Em aberto: a migração para uso custodial ou mediado por LSP é observável, mas não é possível avaliar com seriedade, com os dados de hoje, se as melhorias de protocolo a frenariam ou reverteriam. Prever o impacto em qualquer direção seria especulação.未確定:カストディアル型やLSP経由の利用への流れは観察できるが、プロトコルの改良がそれを減速ないし反転させるかは、現在のデータからは真剣に判断できない。どちらの方向の影響予測も推測にすぎない。悬而未决:用户流向托管或LSP中介使用的趋势可以观察到,但协议升级能否减缓或逆转这一趋势,凭现有数据无法严肃判断。任何方向的影响预测都属推测。مفتوح: الانجراف نحو الاستخدام الوصائي أو عبر مزودي الخدمة ملحوظ، لكن لا يمكن الحكم بجدية من بيانات اليوم عما إذا كانت ترقيات البروتوكول ستبطئه أو تعكسه. وأي توقع للأثر في أي اتجاه يبقى تكهنا.
QuellenSourcesFuentesFontes出典来源المصادر
- BOLT #863 – Splicing Draft (GitHub, lightning/bolts) (github.com)
- Bitcoin BIP 341 – Taproot: SegWit version 1 spending rules (github.com)
- mempool.space – Lightning Network Explorer (mempool.space)
- Bitcoin BIP 340 – Schnorr Signatures for secp256k1 (github.com)