Lightning & SkalierungLightning & ScalingLightning & EscalabilidadLightning & EscalabilidadeLightning & スケーリングLightning & 扩容Lightning & التوسّع
Lightning-Liquidität und Routing-Probleme: Die versteckten Herausforderungen des NetzwerksLightning Liquidity and Routing Problems: The Hidden Challenges of the NetworkLiquidez y problemas de enrutamiento en Lightning: los desafíos ocultos de la redLiquidez e problemas de roteamento no Lightning: os desafios ocultos da redeLightningの流動性とルーティング問題：ネットワークが抱える隠れた課題Lightning 的流动性与路由问题：网络背后的隐藏挑战السيولة ومشكلات التوجيه في Lightning: التحديات الخفية للشبكة
Alle Kernaussagen basieren auf den offiziellen BOLT-Spezifikationen (BOLT #2, #4), dem öffentlich einsehbaren Lightning-Netzwerkgraphen (mempool.space), sowie dokumentierten Produktimplementierungen (Phoenix Wallet v2.0 Splicing, BLIP-0025). Netzwerkzahlen sind mit Stand-Vermerk versehen (Anfang 2026) und als volatil gekennzeichnet. Keine erfundenen Fakten oder Zitate. Score leicht unter 1,0, da Netzwerktopologie-Aussagen (scale-free) auf empirischen Beobachtungen beruhen, die je nach Messzeitpunkt variieren können.All key claims are grounded in official BOLT specifications (BOLT #2, #4), the publicly observable Lightning network graph (mempool.space), and documented production implementations (Phoenix Wallet v2.0 splicing, BLIP-0025). Network figures are labeled with a reference date (early 2026) and flagged as volatile. No invented facts or quotes. Score slightly below 1.0 because scale-free topology claims are based on empirical observations that may vary depending on measurement timing.Todas las afirmaciones clave se basan en las especificaciones oficiales BOLT (BOLT #2, #4), el grafo de red Lightning públicamente observable (mempool.space) y las implementaciones de producción documentadas (Phoenix Wallet v2.0 splicing, BLIP-0025). Las cifras de red están fechadas con una referencia temporal (principios de 2026) y marcadas como volátiles. No hay hechos ni citas inventados. La puntuación es ligeramente inferior a 1,0 porque las afirmaciones sobre la topología libre de escala se basan en observaciones empíricas que pueden variar según el momento de medición.Todas as afirmações principais baseiam-se nas especificações oficiais BOLT (BOLT #2, #4), no grafo da rede Lightning publicamente observável (mempool.space) e em implementações de produção documentadas (Phoenix Wallet v2.0 splicing, BLIP-0025). Os números da rede estão acompanhados de uma data de referência (início de 2026) e sinalizados como voláteis. Nenhum fato ou citação foi inventado. A pontuação fica ligeiramente abaixo de 1,0 porque as afirmações sobre topologia livre de escala baseiam-se em observações empíricas que podem variar conforme o momento da medição.主要な主張はすべて、公式BOLT仕様（BOLT #2、#4）、公開されているLightningネットワークグラフ（mempool.space）、および文書化された本番実装（Phoenix Wallet v2.0スプライシング、BLIP-0025）に基づいている。ネットワークの数値には参照日（2026年初頭）が付記され、変動しやすい旨が明示されている。創作された事実や引用は一切ない。スコアが1.0をわずかに下回るのは、スケールフリートポロジーに関する主張が、測定時点によって異なる可能性のある実証的観察に基づいているためである。所有核心论断均以官方 BOLT 规范（BOLT #2、#4）、可公开观测的 Lightning 网络拓扑图（mempool.space）以及有据可查的生产实现（Phoenix Wallet v2.0 拼接、BLIP-0025）为依据。网络数据附有参考日期标注（2026 年初），并标记为易变数据。无任何捏造的事实或引用。得分略低于 1.0，原因在于无标度拓扑的相关论断基于实证观测，可能因测量时间不同而有所差异。تستند جميع الادعاءات الرئيسية إلى مواصفات BOLT الرسمية (BOLT #2، #4)، وبيان شبكة Lightning المتاح للعموم (mempool.space)، والتطبيقات الإنتاجية الموثقة (Phoenix Wallet v2.0 splicing، BLIP-0025). تُرفق أرقام الشبكة بتاريخ مرجعي (مطلع 2026) وتُصنَّف بوصفها متغيرة. لا توجد أي حقائق أو اقتباسات مخترعة. يقل الدرجة قليلًا عن 1.0 لأن ادعاءات الطوبولوجيا الخالية من المقياس تستند إلى ملاحظات تجريبية قد تتباين وفق توقيت القياس.
Das Lightning Network hat trotz jahrelanger Entwicklung bis Mitte 2026 keine massentaugliche Adoption erreicht; die vom Artikel beschriebenen strukturellen Probleme sind keine Übergangsphänomene, sondern könnten fundamentale Design-Einschränkungen sein. Kritiker wie Matt Corallo und Teile der Bitcoin-Entwicklercommunity bezweifeln, ob ein Kanal-basiertes Off-Chain-System überhaupt ohne Vertrauensintermediäre skalieren kann – eine Position, die im Artikel nicht einmal erwähnt wird. Zudem verschleiert der Begriff 'aktiv weiterentwickeltes Protokoll' die Realität: Kernkonzepte wie Channel Factories existieren seit 2018 als Paper und sind bis heute nicht produktiv; das deutet auf systemische, nicht nur zeitliche Reifeprobleme hin. Leser sollten wissen, dass alternative Layer-2-Ansätze (z. B. Ark, Statechains, Fedimint) zunehmend als ernstzunehmende Alternativen diskutiert werden.Despite years of development, the Lightning Network had not achieved mass-market adoption by mid-2026; the structural problems described in this article may not be transitional phenomena but could reflect fundamental design constraints. Critics such as Matt Corallo and segments of the Bitcoin development community question whether a channel-based off-chain system can scale at all without trust intermediaries – a position the article does not even mention. Furthermore, the phrase 'actively evolving protocol' obscures a telling reality: core concepts like Channel Factories have existed as research papers since 2018 and remain undeployed in production, suggesting systemic rather than merely temporal maturity issues. Readers should also be aware that alternative Layer-2 approaches (e.g., Ark, Statechains, Fedimint) are increasingly discussed as serious contenders.A pesar de años de desarrollo, Lightning Network no había logrado una adopción masiva a mediados de 2026; los problemas estructurales descritos en este artículo podrían no ser fenómenos transitorios, sino reflejar limitaciones fundamentales de diseño. Críticos como Matt Corallo y sectores de la comunidad de desarrollo de Bitcoin cuestionan si un sistema off-chain basado en canales puede escalar sin intermediarios de confianza — una posición que el artículo ni siquiera menciona. Además, la expresión «protocolo en desarrollo activo» oculta una realidad reveladora: conceptos clave como Channel Factories existen como documentos de investigación desde 2018 y aún no han sido desplegados en producción, lo que apunta a problemas de madurez sistémicos y no meramente temporales. Los lectores también deben saber que los enfoques alternativos de Layer 2 (p. ej., Ark, Statechains, Fedimint) se debaten cada vez más como alternativas serias.Apesar de anos de desenvolvimento, o Lightning Network não alcançou adoção em massa até meados de 2026; os problemas estruturais descritos neste artigo podem não ser fenômenos transitórios, mas sim reflexo de restrições fundamentais de design. Críticos como Matt Corallo e parcelas da comunidade de desenvolvimento do Bitcoin questionam se um sistema off-chain baseado em canais consegue escalar sem intermediários de confiança — uma posição que o artigo sequer menciona. Além disso, a expressão "protocolo em desenvolvimento ativo" obscurece uma realidade reveladora: conceitos centrais como Channel Factories existem como artigos de pesquisa desde 2018 e permanecem sem implementação em produção até hoje, o que sugere problemas sistêmicos de maturidade, e não apenas temporais. Os leitores também devem ter em mente que abordagens alternativas de Layer 2 (como Ark, Statechains e Fedimint) são cada vez mais discutidas como alternativas sérias.Lightning Networkは、数年にわたる開発にもかかわらず、2026年半ばの時点で大衆市場への普及を達成できていない。本記事で描かれている構造的な問題は過渡的な現象ではなく、根本的な設計上の制約を反映している可能性がある。Matt Coraloや Bitcoin開発コミュニティの一部は、チャネルベースのオフチェーンシステムが信頼仲介者なしにそもそもスケールできるのかという点に疑問を呈しているが、この見解は本記事で一切言及されていない。さらに、「活発に進化し続けるプロトコル」という表現は、重要な現実を覆い隠している。Channel Factoriesのようなコアコンセプトは2018年から研究論文として存在しているにもかかわらず、今日に至るまで本番環境にデプロイされていない。これは単なる時間的な成熟度の問題ではなく、システム的な問題を示唆している。また、代替のLayer-2アプローチ（例：Ark、Statechains、Fedimint）が真剣な選択肢として議論されるケースが増えていることも、読者は認識しておくべきである。尽管经过多年开发，Lightning Network 截至2026年中期仍未实现大众市场的普及；本文所描述的结构性问题并非过渡性现象，而可能反映了根本性的设计局限。Matt Corallo 等批评者以及 Bitcoin 开发社区的部分成员质疑：一个基于通道的链下系统究竟能否在没有信任中介的情况下实现扩展——而这一立场在本文中甚至未被提及。此外，"持续演进中的协议"这一说法掩盖了一个值得关注的现实：Channel Factories 等核心概念自2018年起便以研究论文的形式存在，至今仍未在生产环境中部署，这表明存在的是系统性成熟度问题，而非单纯的时间问题。读者还应了解，替代性 Layer-2 方案（如 Ark、Statechains、Fedimint）正日益被视为值得认真对待的竞争选项。على الرغم من سنوات من التطوير، لم يحقق شبكة Lightning اعتمادًا جماهيريًا واسعًا حتى منتصف عام 2026؛ والمشكلات الهيكلية التي يصفها هذا المقال قد لا تكون ظواهر مرحلية عابرة، بل قد تعكس قيودًا تصميمية جوهرية. يشكك منتقدون من أمثال Matt Corallo وشرائح من مجتمع مطوري Bitcoin في ما إذا كان بمقدور نظام قائم على القنوات خارج السلسلة أن يتوسع أصلًا دون وسطاء ثقة — وهو موقف لا يُشير إليه المقال حتى بكلمة واحدة. علاوةً على ذلك، يُموّه مصطلح "بروتوكول قيد التطوير المستمر" حقيقةً لافتة: فالمفاهيم الأساسية كـ Channel Factories موجودة في صورة أوراق بحثية منذ عام 2018، ولم تُنشر في بيئات الإنتاج حتى اليوم، مما يُشير إلى مشكلات نضج منهجية وليست مجرد مسألة وقت. وينبغي للقراء أيضًا أن يعلموا أن مقاربات Layer-2 البديلة (مثل Ark وStatechains وFedimint) باتت تُناقَش على نحو متزايد بوصفها بدائل جدية ومعتبرة.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Das Lightning Network gilt als Bitcoins wichtigste Layer-2-Skalierungslösung. Durch bidirektionale Zahlungskanäle können Transaktionen abseits der Blockchain sekundenschnell und mit minimalen Gebühren abgewickelt werden. Doch wer tiefer in die Netzwerkarchitektur blickt, erkennt strukturelle Grenzen, die das Potenzial von Lightning in der Praxis erheblich einschränken.
Das Liquiditätsproblem: Gerichtet und gebunden
Liquidität in Lightning-Kanälen ist immer gebunden und gerichtet. Die Summe aus lokaler und entfernter Balance ergibt die feste Kanalkapazität – Zahlungen können ausschließlich in Richtung der vorhandenen lokalen Balance fließen. Für neue Nodes entsteht Inbound-Liquidität (also die Fähigkeit, Zahlungen zu empfangen) nicht automatisch: Wer einen Kanal öffnet, hält zunächst nur lokale Balance. Ohne Gegenpartei, die ihrerseits Kapital in Richtung des neuen Nodes allokiert, ist der Empfang von Zahlungen nicht möglich.
Dieses strukturelle Onboarding-Problem trifft insbesondere mobile Nutzer und kleine Merchants. Stand Anfang 2026 umfasst das öffentliche Lightning-Netzwerk rund 5.000 BTC gebundene Kapazität, verteilt auf etwa 12.000–15.000 öffentliche Nodes und 50.000–60.000 öffentliche Kanäle (Quelle: mempool.space/lightning). Die Liquidität ist dabei ungleich verteilt.
Routing-Fehler: Opake Fehlermeldungen, komplexe Ursachen
HTLC-Failures (Hash Time Locked Contract-Fehler) sind der häufigste Grund für fehlgeschlagene Lightning-Zahlungen. Sie entstehen durch unzureichende Kanalkapazität auf einem Zwischenknoten, falsch gesetzte Fee-Policies oder Kanäle, die offline gegangen sind. Das zugrundeliegende Onion-Routing-Protokoll (BOLT #4) anonymisiert den Zahlungspfad – mit dem Nebeneffekt, dass der Sender lediglich opake Fehlercodes zurückerhält. Präzises Debugging ist dadurch strukturell erschwert.
Routing-Fees variieren erheblich: Viele Nodes setzen eine Basis-Fee von 1 mSat plus 1 ppm (parts per million) der weitergeleiteten Summe; bei Hubs mit knapper Liquidität können es mehrere hundert ppm sein. Die maximale HTLC-Größe pro Kanal wird durch den Parameter max_htlc_value_in_flight_msat (BOLT #2) gesteuert und liegt je nach Node-Konfiguration bei 1–100 % der Kanalkapazität.
Zentralisierungstendenzen: Das Hub-Problem
Empirische Analysen der Netzwerktopologie zeigen eine skalenfreie (scale-free) Struktur: Wenige hochgradig vernetzte Hub-Nodes konzentrieren den Großteil des Routings auf sich. Diese Konzentration schafft Single Points of Failure und potenzielle Zensurpunkte – ein Widerspruch zum Dezentralisierungsideal von Bitcoin. Je mehr Nutzer auf dieselben großen Hubs angewiesen sind, desto größer wird die strukturelle Abhängigkeit vom Wohlverhalten dieser Intermediäre.
Eine skalenfreie Netzwerktopologie bedeutet: Wenige Knoten akkumulieren überproportional viele Verbindungen. Fällt ein solcher Hub aus, können Zahlungen für viele Teilnehmer gleichzeitig scheitern.
Lightning Service Providers (LSPs): Komfort gegen Vertrauen
Lightning Service Providers wie ACINQ (Phoenix Wallet), Voltage oder Breez adressieren das Onboarding-Liquiditätsproblem durch Just-in-Time (JIT) Kanalöffnung: Sobald ein neuer Nutzer eine Zahlung empfangen möchte, öffnet der LSP automatisch einen Kanal mit der nötigen Inbound-Liquidität. Phoenix Wallet erhebt dafür (Stand 2024/2025) eine Gebühr von 1 % der Zahlungssumme plus 3.000 Sat Mindestgebühr. Liquidity Ads (über BOLTs/BLIPs spezifiziert) ermöglichen darüber hinaus einen marktbasierten Mechanismus, über den Nodes Liquidität anbieten und nachfragen können. Der Preis dieser Komfortlösung: neue Vertrauensabhängigkeiten gegenüber dem LSP als zentralem Intermediär.
Splicing: Dynamische Liquidität ohne Kanalschließung
Splicing (im Entwurf von BOLT #2) erlaubt das Hinzufügen oder Entfernen von Kapital aus einem bestehenden Kanal ohne dessen Schließung. Dies ist ein wesentlicher Schritt zur dynamischen Liquiditätsverwaltung: Node-Betreiber können ihre Kanalkapazitäten anpassen, ohne eine teure On-Chain-Transaktion für Schließung und Neuöffnung durchführen zu müssen. Phoenix Wallet hat Splicing als erste Wallet produktiv implementiert – ab Version 2.0 im April 2023.
Channel Factories und Trampoline Routing: Zukunft der Skalierung
Channel Factories erlauben das Bündeln mehrerer Kanäle in einer einzigen On-Chain-Transaktion über Multi-Party-Konstrukte. Der On-Chain-Footprint des Lightning-Netzwerks könnte dadurch erheblich reduziert werden. Stand 2026 befindet sich dieses Konzept jedoch noch in der Forschungs- und Spezifikationsphase und ist nicht produktiv einsetzbar.
Trampoline Routing (BLIP-0025, maßgeblich von ACINQ vorangetrieben) delegiert die aufwendige Routing-Berechnung an spezialisierte Trampoline-Nodes im Netzwerk. Mobile Wallets müssen so keinen vollständigen Netzwerkgraphen vorhalten – eine wesentliche Voraussetzung für nutzerfreundliche Lightning-Clients auf ressourcenschwachen Geräten.
Fazit: Strukturelle Grenzen, aktive Lösungswege
Das Lightning Network ist kein fertiges System, sondern ein aktiv weiterentwickeltes Protokoll mit bekannten strukturellen Grenzen. Inbound-Liquidität, Routing-Zuverlässigkeit und Zentralisierungstendenzen sind reale Herausforderungen – keine Randnotizen. Die Lösungsansätze (LSPs, Splicing, Channel Factories, Trampoline Routing) befinden sich in unterschiedlichen Reifegraden. Entscheidend wird sein, ob sie die Dezentralisierung des Netzwerks stärken oder – durch neue Intermediäre – weiter untergraben.
Weiterführend
The Lightning Network is widely regarded as Bitcoin's most important Layer-2 scaling solution. Bidirectional payment channels enable transactions to be settled off-chain in seconds with minimal fees. Yet a closer look at the network's architecture reveals structural limitations that significantly constrain Lightning's practical potential.
The Liquidity Problem: Directional and Locked
Liquidity in Lightning channels is always locked and directional. The sum of local and remote balance equals the fixed channel capacity – payments can only flow in the direction of the available local balance. For new nodes, inbound liquidity (the ability to receive payments) does not arise automatically: opening a channel initially provides only local balance. Without a counterparty allocating capital toward the new node, receiving payments is impossible.
This structural onboarding problem is especially acute for mobile users and small merchants. As of early 2026, the public Lightning Network holds approximately 5,000 BTC in locked capacity, spread across roughly 12,000–15,000 public nodes and 50,000–60,000 public channels (source: mempool.space/lightning). That liquidity is distributed highly unevenly.
Routing Failures: Opaque Error Codes, Complex Causes
HTLC failures (Hash Time Locked Contract failures) are the most common reason Lightning payments fail. They stem from insufficient channel capacity at an intermediate node, misconfigured fee policies, or channels that have gone offline. The underlying onion-routing protocol (BOLT #4) anonymizes the payment path – with the side effect that the sender receives only opaque error codes. Precise debugging is structurally difficult as a result.
Routing fees vary considerably: many nodes set a base fee of 1 mSat plus 1 ppm (parts per million) of the forwarded amount; hubs with tight liquidity may charge several hundred ppm. The maximum HTLC size per channel is governed by the max_htlc_value_in_flight_msat parameter (BOLT #2) and ranges from 1–100% of channel capacity depending on node configuration.
Centralization Tendencies: The Hub Problem
Empirical analyses of the network topology reveal a scale-free structure: a small number of highly connected hub nodes concentrate the majority of routing traffic. This concentration creates single points of failure and potential censorship vectors – a contradiction of Bitcoin's decentralization ideal. The more users depend on the same large hubs, the greater the structural reliance on those intermediaries behaving honestly.
A scale-free network topology means that a small number of nodes accumulate a disproportionate share of connections. If such a hub goes offline, payments for many participants can fail simultaneously.
Lightning Service Providers (LSPs): Convenience vs. Trust
Lightning Service Providers such as ACINQ (Phoenix Wallet), Voltage, and Breez address the onboarding liquidity problem through Just-in-Time (JIT) channel opening: when a new user wants to receive a payment, the LSP automatically opens a channel with the necessary inbound liquidity. Phoenix Wallet charges (as of 2024/2025) a fee of 1% of the payment amount plus a minimum of 3,000 sat for this service. Liquidity Ads (specified via BOLTs/BLIPs) additionally enable a market-based mechanism through which nodes can advertise and purchase liquidity. The price of this convenience: new trust dependencies on the LSP as a central intermediary.
Splicing: Dynamic Liquidity Without Closing Channels
Splicing (drafted in BOLT #2) allows capital to be added to or removed from an existing channel without closing it. This is a significant step toward dynamic liquidity management: node operators can adjust channel capacities without incurring the cost of an on-chain close-and-reopen cycle. Phoenix Wallet was the first wallet to implement splicing in production – with version 2.0 in April 2023.
Channel Factories and Trampoline Routing: The Future of Scaling
Channel Factories allow multiple channels to be bundled into a single on-chain transaction via multi-party constructs. This could substantially reduce the on-chain footprint of the Lightning Network. As of 2026, however, this concept remains in the research and specification phase and is not yet available in production.
Trampoline Routing (BLIP-0025, primarily advanced by ACINQ) delegates the computationally intensive routing calculation to specialized trampoline nodes in the network. Mobile wallets no longer need to maintain a full network graph – a key prerequisite for user-friendly Lightning clients on resource-constrained devices.
Conclusion: Structural Limits, Active Solutions
The Lightning Network is not a finished system but an actively evolving protocol with well-documented structural limits. Inbound liquidity, routing reliability, and centralization tendencies are real challenges – not footnotes. The proposed solutions (LSPs, splicing, channel factories, trampoline routing) exist at varying stages of maturity. The critical question is whether they will strengthen the network's decentralization or – by introducing new intermediaries – further erode it.
Related
La Lightning Network es ampliamente considerada la solución de escalabilidad de capa 2 más importante de Bitcoin. Los canales de pago bidireccionales permiten liquidar transacciones fuera de la cadena en segundos y con comisiones mínimas. Sin embargo, una mirada más profunda a la arquitectura de la red revela limitaciones estructurales que restringen considerablemente el potencial práctico de Lightning.
El problema de liquidez: direccional y bloqueada
La liquidez en los canales de Lightning siempre está bloqueada y es direccional. La suma del saldo local y el saldo remoto equivale a la capacidad fija del canal; los pagos solo pueden fluir en la dirección del saldo local disponible. Para los nuevos nodos, la liquidez entrante (la capacidad de recibir pagos) no surge de forma automática: abrir un canal inicialmente solo proporciona saldo local. Sin una contraparte que asigne capital hacia el nuevo nodo, recibir pagos es imposible.
Este problema estructural de incorporación afecta especialmente a los usuarios móviles y a los pequeños comerciantes. A principios de 2026, la Lightning Network pública alberga aproximadamente 5.000 BTC de capacidad bloqueada, distribuida entre unos 12.000–15.000 nodos públicos y 50.000–60.000 canales públicos (fuente: mempool.space/lightning). Dicha liquidez está distribuida de manera muy desigual.
Fallos de enrutamiento: códigos de error opacos, causas complejas
Los fallos de HTLC (Hash Time Locked Contract) son el motivo más frecuente de los pagos fallidos en Lightning. Se originan por capacidad insuficiente en un nodo intermedio, políticas de comisiones mal configuradas o canales que se han desconectado. El protocolo de enrutamiento cebolla subyacente (BOLT #4) anonimiza la ruta de pago, con el efecto secundario de que el emisor solo recibe códigos de error opacos. La depuración precisa resulta, por tanto, estructuralmente difícil.
Las comisiones de enrutamiento varían considerablemente: muchos nodos establecen una comisión base de 1 mSat más 1 ppm (partes por millón) del importe reenviado; los hubs con liquidez ajustada pueden cobrar varios cientos de ppm. El tamaño máximo de HTLC por canal está regulado por el parámetro max_htlc_value_in_flight_msat (BOLT #2) y oscila entre el 1 y el 100 % de la capacidad del canal según la configuración del nodo.
Tendencias a la centralización: el problema de los hubs
Los análisis empíricos de la topología de la red revelan una estructura libre de escala (scale-free): un pequeño número de nodos hub altamente conectados concentra la mayor parte del tráfico de enrutamiento. Esta concentración genera puntos únicos de fallo y potenciales vectores de censura, una contradicción con el ideal de descentralización de Bitcoin. Cuanto más usuarios dependen de los mismos grandes hubs, mayor es la dependencia estructural del comportamiento honesto de esos intermediarios.
Una topología de red libre de escala implica que un pequeño número de nodos acumula una proporción desproporcionada de conexiones. Si uno de esos hubs se desconecta, los pagos de muchos participantes pueden fallar simultáneamente.
Lightning Service Providers (LSPs): comodidad frente a confianza
Los Lightning Service Providers como ACINQ (Phoenix Wallet), Voltage y Breez abordan el problema de liquidez en la incorporación mediante la apertura de canales Just-in-Time (JIT): cuando un nuevo usuario desea recibir un pago, el LSP abre automáticamente un canal con la liquidez entrante necesaria. Phoenix Wallet cobra (a partir de 2024/2025) una comisión del 1 % del importe del pago más una comisión mínima de 3.000 sat por este servicio. Los Liquidity Ads (especificados mediante BOLTs/BLIPs) habilitan además un mecanismo de mercado a través del cual los nodos pueden ofrecer y adquirir liquidez. El precio de esta comodidad: nuevas dependencias de confianza en el LSP como intermediario central.
Splicing: liquidez dinámica sin cerrar canales
El splicing (en borrador en BOLT #2) permite añadir o retirar capital de un canal existente sin cerrarlo. Este es un paso significativo hacia la gestión dinámica de liquidez: los operadores de nodos pueden ajustar las capacidades de sus canales sin incurrir en el coste de cerrar y reabrir un canal en cadena. Phoenix Wallet fue la primera wallet en implementar el splicing en producción, con la versión 2.0 en abril de 2023.
Channel Factories y Trampoline Routing: el futuro del escalado
Las Channel Factories permiten agrupar múltiples canales en una única transacción en cadena mediante construcciones multiparte. Esto podría reducir sustancialmente la huella en cadena de la Lightning Network. Sin embargo, a fecha de 2026, este concepto sigue en fase de investigación y especificación y aún no está disponible en producción.
El Trampoline Routing (BLIP-0025, impulsado principalmente por ACINQ) delega el cálculo de enrutamiento, computacionalmente intensivo, a nodos trampolín especializados en la red. Las wallets móviles ya no necesitan mantener un grafo completo de la red, lo que constituye un requisito clave para clientes Lightning fáciles de usar en dispositivos con recursos limitados.
Conclusión: límites estructurales, soluciones activas
La Lightning Network no es un sistema terminado, sino un protocolo en evolución activa con limitaciones estructurales bien documentadas. La liquidez entrante, la fiabilidad del enrutamiento y las tendencias a la centralización son desafíos reales, no notas al margen. Las soluciones propuestas (LSPs, splicing, channel factories, trampoline routing) se encuentran en distintos grados de madurez. La pregunta clave es si fortalecerán la descentralización de la red o si, al introducir nuevos intermediarios, la erosionarán aún más.
Más información
A Lightning Network é amplamente considerada a solução de escalabilidade Layer-2 mais importante do Bitcoin. Os canais de pagamento bidirecionais permitem que transações sejam liquidadas fora da blockchain em segundos, com taxas mínimas. No entanto, uma análise mais aprofundada da arquitetura da rede revela limitações estruturais que restringem consideravelmente o potencial prático da Lightning.
O Problema de Liquidez: Direcional e Bloqueada
A liquidez nos canais Lightning é sempre bloqueada e direcional. A soma do saldo local e do saldo remoto corresponde à capacidade fixa do canal – os pagamentos só podem fluir na direção do saldo local disponível. Para novos nodes, a liquidez de entrada (ou seja, a capacidade de receber pagamentos) não surge automaticamente: abrir um canal inicialmente fornece apenas saldo local. Sem uma contraparte que aloque capital na direção do novo node, receber pagamentos é impossível.
Este problema estrutural de integração afeta especialmente utilizadores móveis e pequenos comerciantes. No início de 2026, a rede Lightning pública detém aproximadamente 5.000 BTC em capacidade bloqueada, distribuídos por cerca de 12.000–15.000 nodes públicos e 50.000–60.000 canais públicos (fonte: mempool.space/lightning). Essa liquidez está distribuída de forma bastante desigual.
Falhas de Roteamento: Códigos de Erro Opacos, Causas Complexas
As falhas de HTLC (Hash Time Locked Contract) são o motivo mais comum para pagamentos Lightning falharem. Resultam de capacidade insuficiente num node intermediário, políticas de taxas mal configuradas ou canais que ficaram offline. O protocolo de onion-routing subjacente (BOLT #4) anonimiza o caminho do pagamento – com o efeito colateral de que o remetente recebe apenas códigos de erro opacos. O diagnóstico preciso torna-se assim estruturalmente difícil.
As taxas de roteamento variam consideravelmente: muitos nodes definem uma taxa base de 1 mSat mais 1 ppm (partes por milhão) do valor encaminhado; hubs com liquidez escassa podem cobrar várias centenas de ppm. O tamanho máximo de HTLC por canal é controlado pelo parâmetro max_htlc_value_in_flight_msat (BOLT #2) e varia entre 1–100% da capacidade do canal, consoante a configuração do node.
Tendências de Centralização: O Problema dos Hubs
Análises empíricas da topologia da rede revelam uma estrutura livre de escala (scale-free): um pequeno número de nodes hub altamente conectados concentra a grande maioria do tráfego de roteamento. Esta concentração cria pontos únicos de falha e potenciais vetores de censura – uma contradição com o ideal de descentralização do Bitcoin. Quanto mais utilizadores dependem dos mesmos grandes hubs, maior se torna a dependência estrutural do comportamento honesto desses intermediários.
Uma topologia de rede livre de escala significa que um pequeno número de nodes acumula uma parte desproporcionalmente elevada das ligações. Se um desses hubs ficar offline, os pagamentos de muitos participantes podem falhar simultaneamente.
Lightning Service Providers (LSPs): Conveniência versus Confiança
Os Lightning Service Providers como a ACINQ (Phoenix Wallet), Voltage e Breez resolvem o problema de liquidez de integração através da abertura de canais Just-in-Time (JIT): quando um novo utilizador pretende receber um pagamento, o LSP abre automaticamente um canal com a liquidez de entrada necessária. A Phoenix Wallet cobra (em 2024/2025) uma taxa de 1% do valor do pagamento mais uma taxa mínima de 3.000 sat por este serviço. Os Liquidity Ads (especificados via BOLTs/BLIPs) permitem ainda um mecanismo baseado no mercado, através do qual os nodes podem oferecer e solicitar liquidez. O custo desta comodidade: novas dependências de confiança no LSP como intermediário central.
Splicing: Liquidez Dinâmica sem Fechar Canais
O Splicing (previsto no rascunho do BOLT #2) permite adicionar ou remover capital de um canal existente sem encerrá-lo. Trata-se de um passo fundamental para a gestão dinâmica de liquidez: os operadores de nodes podem ajustar as capacidades dos seus canais sem incorrer no custo de uma transação on-chain de encerramento e reabertura. A Phoenix Wallet foi a primeira wallet a implementar o splicing em produção – a partir da versão 2.0, em abril de 2023.
Channel Factories e Trampoline Routing: O Futuro da Escalabilidade
As Channel Factories permitem agrupar vários canais numa única transação on-chain através de construções multi-parte. Isto poderia reduzir substancialmente a pegada on-chain da Lightning Network. Em 2026, porém, este conceito encontra-se ainda na fase de investigação e especificação, não estando disponível em produção.
O Trampoline Routing (BLIP-0025, impulsionado principalmente pela ACINQ) delega o cálculo de roteamento computacionalmente intensivo a nodes trampoline especializados na rede. As wallets móveis deixam assim de precisar de manter um grafo completo da rede – um requisito essencial para clientes Lightning intuitivos em dispositivos com recursos limitados.
Conclusão: Limites Estruturais, Soluções em Desenvolvimento
A Lightning Network não é um sistema acabado, mas sim um protocolo em evolução ativa, com limitações estruturais bem documentadas. A liquidez de entrada, a fiabilidade do roteamento e as tendências de centralização são desafios reais – não meras notas de rodapé. As soluções propostas (LSPs, splicing, channel factories, trampoline routing) encontram-se em diferentes graus de maturidade. A questão decisiva é se irão fortalecer a descentralização da rede ou – ao introduzir novos intermediários – erodi-la ainda mais.
Mais informação
Lightning Networkは、Bitcoinで最も重要なレイヤー2スケーリングソリューションとして広く認められています。双方向ペイメントチャネルにより、オフチェーンでの取引を数秒かつ最小限の手数料で決済することが可能です。しかし、ネットワークアーキテクチャを深く見ると、Lightningの実用的なポテンシャルを大きく制約する構造的な限界が浮かび上がってきます。
流動性問題：方向性と拘束
Lightningチャネルの流動性は、常に拘束されており方向性を持ちます。ローカル残高とリモート残高の合計が固定チャネル容量となり、支払いは利用可能なローカル残高の方向にしか流れません。新しいノードにとって、インバウンド流動性（支払いを受け取る能力）は自動的に生まれません。チャネルを開いた時点では、最初にローカル残高のみが存在します。新しいノードに向けて資本を割り当てる相手方がいなければ、支払いの受け取りは不可能です。
この構造的なオンボーディング問題は、モバイルユーザーや小規模マーチャントに特に大きな影響を与えます。2026年初頭時点で、公開Lightning Networkは約5,000 BTCの拘束容量を保有しており、約12,000〜15,000の公開ノードと50,000〜60,000の公開チャネルに分散しています（出典：mempool.space/lightning）。その流動性は非常に不均等に分布しています。
ルーティング失敗：不透明なエラーコード、複雑な原因
HTLC失敗（Hash Time Locked Contractエラー）は、Lightningの支払いが失敗する最も一般的な原因です。これらは、中間ノードでのチャネル容量不足、誤って設定された手数料ポリシー、またはオフラインになったチャネルによって引き起こされます。基盤となるオニオンルーティングプロトコル（BOLT #4）は支払い経路を匿名化しており、その副作用として送信者には不透明なエラーコードしか返されません。その結果、精密なデバッグは構造的に困難になっています。
ルーティング手数料は大きく異なります。多くのノードは1 mSatの基本手数料に加え、転送金額の1 ppm（parts per million）を設定しています。流動性が逼迫したハブでは数百 ppmに達することもあります。チャネルあたりの最大HTLC サイズはmax_htlc_value_in_flight_msatパラメータ（BOLT #2）によって管理され、ノード設定に応じてチャネル容量の1〜100%の範囲となります。
中央集権化の傾向：ハブ問題
ネットワークトポロジーの実証分析により、スケールフリー（scale-free）構造が明らかになっています。高度に接続された少数のハブノードがルーティングトラフィックの大部分を集中させています。この集中は単一障害点と潜在的な検閲ポイントを生み出し、Bitcoinの分散化の理念と矛盾します。同じ大規模ハブに依存するユーザーが増えるほど、それらの仲介者の誠実な行動への構造的依存度が高まります。
スケールフリーなネットワークトポロジーとは、少数のノードが不均衡に多くの接続を集積することを意味します。このようなハブが停止すると、多くの参加者の支払いが同時に失敗する可能性があります。
Lightning Service Providers（LSPs）：利便性とトラスト
ACINQ（Phoenix Wallet）、Voltage、BreezなどのLightning Service Providerは、Just-in-Time（JIT）チャネル開設によりオンボーディングの流動性問題に対処しています。新しいユーザーが支払いを受け取ろうとすると、LSPが必要なインバウンド流動性を備えたチャネルを自動的に開設します。Phoenix Walletは（2024/2025年時点で）このサービスに対して支払い金額の1%に加え、最低3,000 Satの手数料を徴収します。Liquidity Ads（BOLTs/BLIPsで規定）は、ノードが流動性を提供・要求できる市場ベースのメカニズムも提供しています。この利便性の代償は、中央仲介者としてのLSPへの新たな信頼依存です。
Splicing：チャネルを閉鎖せずに動的な流動性管理
Splicing（BOLT #2の草案）は、既存のチャネルを閉鎖することなく資本を追加または削除することを可能にします。これは動的な流動性管理への重要な一歩です。ノードオペレーターは、オンチェーンでのクローズと再開設のコストを負うことなく、チャネル容量を調整できます。Phoenix Walletは2023年4月のバージョン2.0から、初めてSplicingを本番環境で実装したウォレットとなりました。
Channel FactoriesとTrampoline Routing：スケーリングの未来
Channel Factoriesは、マルチパーティ構造を通じて複数のチャネルを単一のオンチェーントランザクションにまとめることを可能にします。これによりLightning Networkのオンチェーンフットプリントを大幅に削減できる可能性があります。ただし、2026年時点ではこのコンセプトはまだ研究・仕様策定段階にあり、本番環境では利用できません。
Trampoline Routing（BLIP-0025、主にACINQが推進）は、計算負荷の高いルーティング計算をネットワーク内の専門的なトランポリンノードに委譲します。これにより、モバイルウォレットは完全なネットワークグラフを保持する必要がなくなり、リソースが限られたデバイス上でのユーザーフレンドリーなLightningクライアントを実現するための重要な前提条件となります。
まとめ：構造的な限界と積極的な解決策
Lightning Networkは完成されたシステムではなく、よく知られた構造的な限界を持ちながら活発に進化し続けるプロトコルです。インバウンド流動性、ルーティングの信頼性、中央集権化の傾向は、脚注ではなく現実の課題です。提案されている解決策（LSPs、Splicing、Channel Factories、Trampoline Routing）は、それぞれ異なる成熟度の段階にあります。重要な問いは、それらがネットワークの分散化を強化するのか、あるいは新たな仲介者の導入によってさらに損なうのか、という点です。
関連情報
Lightning Network 被公认为 Bitcoin 最重要的二层扩容方案。双向支付通道使交易得以在链下以秒级速度完成结算，且手续费极低。然而，深入审视其网络架构，便会发现若干结构性局限，在实践中显著制约了 Lightning 的潜力。
流动性问题：有向且锁定
Lightning 通道中的流动性始终是锁定且有方向性的。本地余额与远端余额之和构成固定的通道容量——付款只能沿本地余额可用的方向流动。对于新节点而言，入站流动性（即接收付款的能力）不会自动产生：开通通道后，最初只持有本地余额。若没有对手方将资金分配至新节点方向，则无法接收付款。
这一结构性的入网问题对移动用户和小型商户尤为突出。截至 2026 年初，公开的 Lightning 网络锁定容量约为 5,000 BTC，分布于约 12,000–15,000 个公开节点和 50,000–60,000 条公开通道（数据来源：mempool.space/lightning）。这些流动性的分布极不均衡。
路由失败：不透明的错误码，复杂的成因
HTLC 失败（Hash Time Locked Contract 失败）是 Lightning 付款失败最常见的原因。其成因包括：中间节点通道容量不足、手续费策略配置错误，或通道已离线。底层洋葱路由协议（BOLT #4）对支付路径进行匿名化处理——副作用是发送方仅能收到不透明的错误码，导致精确调试在结构上存在相当难度。
路由费用差异显著：许多节点设定的基础费为 1 mSat 加转发金额的 1 ppm（百万分之一）；流动性紧张的枢纽节点可能收取数百 ppm。每条通道的最大 HTLC 金额由参数 max_htlc_value_in_flight_msat（BOLT #2）控制，依节点配置不同，范围为通道容量的 1%–100%。
中心化倾向：枢纽问题
对网络拓扑的实证分析揭示了一种无标度（scale-free）结构：少数高度互联的枢纽节点集中了绝大部分路由流量。这种集中化造成了单点故障和潜在的审查风险——与 Bitcoin 去中心化的理想相悖。越多用户依赖相同的大型枢纽，对这些中间方诚实行为的结构性依赖就越深。
无标度网络拓扑意味着：少数节点积累了不成比例的大量连接。一旦某个枢纽节点离线，许多参与者的付款可能同时失败。
Lightning 服务提供商（LSP）：便利与信任的权衡
ACINQ（Phoenix Wallet）、Voltage 和 Breez 等 Lightning 服务提供商通过即时（JIT）通道开通来解决入网流动性问题：当新用户希望接收付款时，LSP 会自动开通一条具备所需入站流动性的通道。为此，Phoenix Wallet（截至 2024/2025 年）收取付款金额的 1% 加最低 3,000 sat 的费用。流动性广告（通过 BOLTs/BLIPs 规范）还提供了一种基于市场的机制，节点可通过该机制提供和购买流动性。此类便利方案的代价是：对 LSP 这一中心化中间方产生新的信任依赖。
Splicing：无需关闭通道的动态流动性管理
Splicing（在 BOLT #2 草案中定义）允许在不关闭现有通道的情况下向其增加或移除资金。这是迈向动态流动性管理的重要一步：节点运营者可以调整通道容量，而无需承担关闭再重开的高额链上交易成本。Phoenix Wallet 是首个将 Splicing 投入生产环境的钱包——于 2023 年 4 月随 2.0 版本上线。
Channel Factories 与 Trampoline Routing：扩容的未来
Channel Factories 允许通过多方构造将多条通道打包进一笔链上交易，从而大幅降低 Lightning 网络的链上占用。截至 2026 年，该概念仍处于研究和规范阶段，尚未可用于生产环境。
Trampoline Routing（BLIP-0025，主要由 ACINQ 推动）将计算密集型的路由计算委托给网络中的专用蹦床节点。移动钱包无需再维护完整的网络图谱——这是在资源受限设备上实现用户友好型 Lightning 客户端的关键前提。
结语：结构性局限与积极应对
Lightning Network 并非一个完善的系统，而是一个仍在积极演进、存在已知结构性局限的协议。入站流动性、路由可靠性和中心化倾向是真实存在的挑战，而非无关紧要的注脚。各类解决方案（LSP、Splicing、Channel Factories、Trampoline Routing）处于不同的成熟阶段。关键问题在于：它们究竟能强化网络的去中心化，还是会因引入新的中间方而进一步削弱它。
延伸阅读
تُعدّ شبكة Lightning الحلَّ الأبرز لتوسيع نطاق Bitcoin على الطبقة الثانية. إذ تتيح قنوات الدفع ثنائية الاتجاه إتمامَ المعاملات خارج سلسلة الكتل في ثوانٍ معدودة وبرسوم ضئيلة للغاية. غير أن التعمق في بنية الشبكة يكشف عن قيود هيكلية تُضيّق بشكل ملحوظ من الإمكانات العملية لـ Lightning.
مشكلة السيولة: اتجاهية ومجمَّدة
السيولة في قنوات Lightning مجمَّدة دائمًا وذات اتجاه محدد. فمجموع الرصيد المحلي والرصيد البعيد يساوي سعة القناة الثابتة، ولا يمكن تدفق المدفوعات إلا في اتجاه الرصيد المحلي المتاح. بالنسبة للعُقد الجديدة، لا تنشأ سيولة الاستقبال (أي القدرة على استقبال المدفوعات) تلقائيًا: فعند فتح قناة، يتوفر في البداية رصيد محلي فحسب. ومن دون طرف مقابل يُخصّص رأس مال باتجاه العقدة الجديدة، يصبح استقبال المدفوعات مستحيلًا.
تمسّ هذه المشكلة الهيكلية في الانضمام بشكل خاص المستخدمين على الأجهزة المحمولة وصغار التجار. وفي مطلع عام 2026، تضمّ شبكة Lightning العامة ما يقارب 5,000 BTC من السعة المجمَّدة، موزَّعة على نحو 12,000–15,000 عقدة عامة و50,000–60,000 قناة عامة (المصدر: mempool.space/lightning)، وتتوزع هذه السيولة بشكل غير متكافئ.
إخفاقات التوجيه: رسائل خطأ معتمة وأسباب معقدة
تُعدّ إخفاقات HTLC (أخطاء عقود Hash Time Locked) السببَ الأكثر شيوعًا لفشل مدفوعات Lightning. وتنجم عن عدم كفاية سعة القناة في عقدة وسيطة، أو سياسات رسوم مُعدَّة بشكل خاطئ، أو قنوات انقطعت عن الشبكة. يُخفي بروتوكول التوجيه البصلي الأساسي (BOLT #4) مسار الدفع لضمان الخصوصية، مما يُفضي إلى أن يتلقى المُرسِل رموز خطأ معتمة فحسب، وهو ما يُصعّب عملية تشخيص الأخطاء بشكل هيكلي.
تتفاوت رسوم التوجيه تفاوتًا ملحوظًا: تضع كثير من العقد رسومًا أساسية قدرها 1 mSat إضافةً إلى 1 ppm (جزء في المليون) من المبلغ المُحوَّل؛ وقد تصل الرسوم في المحاور ذات السيولة الضيقة إلى عدة مئات من الـ ppm. ويتحكم المعامل max_htlc_value_in_flight_msat (BOLT #2) في الحجم الأقصى لـ HTLC لكل قناة، ويتراوح بين 1–100% من سعة القناة تبعًا لإعدادات العقدة.
نزعات المركزية: مشكلة المحاور
تكشف التحليلات التجريبية لطوبولوجيا الشبكة عن بنية خالية من المقياس (scale-free): إذ تتمركز غالبية حركة التوجيه في عدد قليل من عقد المحاور عالية الترابط. يُفرز هذا التمركز نقاط فشل منفردة ونقاط رقابة محتملة، مما يتعارض مع مبدأ اللامركزية الذي يقوم عليه Bitcoin. وكلما ازداد اعتماد المستخدمين على المحاور الكبرى ذاتها، تعمّقت التبعية الهيكلية لحسن تصرف هؤلاء الوسطاء.
تعني طوبولوجيا الشبكة الخالية من المقياس أن عددًا قليلًا من العقد يتراكم لديها نصيب غير متناسب من الاتصالات. فإذا تعطّل أحد هذه المحاور، قد تفشل المدفوعات لكثير من المشاركين في آنٍ واحد.
مزودو خدمات Lightning (LSPs): الراحة مقابل الثقة
يعالج مزودو خدمات Lightning أمثال ACINQ (Phoenix Wallet) وVoltage وBreez مشكلة سيولة الانضمام من خلال فتح القنوات في الوقت المناسب (Just-in-Time - JIT): فحين يرغب مستخدم جديد في استقبال دفعة، يفتح مزود الخدمة تلقائيًا قناةً بسيولة الاستقبال اللازمة. وتفرض Phoenix Wallet (اعتبارًا من 2024/2025) رسومًا بنسبة 1% من مبلغ الدفعة بالإضافة إلى حد أدنى قدره 3,000 Sat مقابل هذه الخدمة. كما تتيح إعلانات السيولة (Liquidity Ads، المحددة عبر BOLTs/BLIPs) آليةً قائمة على السوق تُمكّن العقد من عرض السيولة وطلبها. غير أن ثمن هذه الراحة هو نشوء تبعيات ثقة جديدة تجاه مزود الخدمة بوصفه وسيطًا مركزيًا.
Splicing: سيولة ديناميكية دون إغلاق القنوات
يتيح Splicing (المُقترَح في BOLT #2) إضافة رأس المال إلى قناة قائمة أو سحبه منها دون إغلاقها. وهذا خطوة جوهرية نحو إدارة السيولة الديناميكية: إذ يستطيع مشغلو العقد تعديل سعات قنواتهم دون الحاجة إلى إجراء معاملة مكلفة على السلسلة لإغلاق القناة وإعادة فتحها. وكانت Phoenix Wallet أول محفظة تُطبّق Splicing في بيئة الإنتاج، اعتبارًا من الإصدار 2.0 في أبريل 2023.
Channel Factories وTrampoline Routing: مستقبل التوسع
تتيح Channel Factories تجميع عدة قنوات في معاملة واحدة على السلسلة عبر بنى متعددة الأطراف، مما قد يُقلّص بشكل ملحوظ من البصمة على السلسلة لشبكة Lightning. غير أن هذا المفهوم لا يزال حتى عام 2026 في مرحلة البحث والتحديد، ولم يُتَح بعد في بيئات الإنتاج.
يُفوّض Trampoline Routing (BLIP-0025، الذي تقوده ACINQ بشكل رئيسي) حسابات التوجيه المعقدة إلى عقد trampoline متخصصة في الشبكة. وهكذا لا تحتاج المحافظ على الأجهزة المحمولة إلى الاحتفاظ برسم بياني كامل للشبكة، وهو شرط أساسي لتوفير عملاء Lightning سهلي الاستخدام على الأجهزة محدودة الموارد.
خلاصة: قيود هيكلية وحلول فاعلة
شبكة Lightning ليست نظامًا مكتمل البناء، بل بروتوكول في تطور مستمر تشوبه قيود هيكلية موثّقة. فسيولة الاستقبال، وموثوقية التوجيه، ونزعات المركزية تمثّل تحديات حقيقية لا هوامش. والحلول المقترحة (مزودو خدمات Lightning، وSplicing، وChannel Factories، وTrampoline Routing) في مراحل متباينة من النضج. والسؤال المحوري هو: هل ستعزز هذه الحلول لامركزية الشبكة، أم ستزيد من تآكلها من خلال إدخال وسطاء جدد؟
مزيد من المعلومات
⚖️ 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.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
Die beschriebenen Grenzen könnten fundamental statt übergangsweise sein: Jeder selbstverwahrende Lightning-Nutzer braucht On-Chain-Transaktionen, und die Blockraum-Arithmetik deckelt die non-custodiale Massenadoption, solange Konstrukte wie Channel Factories nicht existieren.The limits described may be fundamental rather than transitional: every self-custodial Lightning user needs on-chain transactions, and block-space arithmetic caps non-custodial mass adoption as long as constructs like channel factories do not exist.Los límites descritos podrían ser fundamentales y no transitorios: cada usuario de Lightning en autocustodia necesita transacciones on-chain, y la aritmética del espacio de bloque limita la adopción masiva no custodial mientras no existan constructos como las channel factories.Os limites descritos podem ser fundamentais, não transitórios: cada usuário de Lightning em autocustódia precisa de transações on-chain, e a aritmética do espaço de bloco limita a adoção em massa não custodial enquanto construtos como channel factories não existirem.記事が描く限界は過渡的ではなく根本的かもしれない。自己管理型のLightningユーザーは全員オンチェーン取引を必要とし、Channel Factoriesのような構想が存在しない限り、ブロックスペースの算術がノンカストディアルの大量普及に上限を課す。文中描述的限制可能是根本性的而非过渡性的:每个自我保管的Lightning用户都需要链上交易,只要Channel Factories这类构想尚不存在,区块空间的算术就为非托管的大规模普及设定了上限。قد تكون الحدود الموصوفة جوهرية لا انتقالية: فكل مستخدم Lightning يحتفظ بمفاتيحه يحتاج إلى معاملات على السلسلة، وحسابات مساحة الكتل تسقف التبني الجماهيري غير الوصائي ما دامت بنى مثل Channel Factories غير موجودة.
Belegt: Die Kapazitätsarithmetik ist unstrittig, und der Artikel bestätigt selbst, dass Channel Factories 2026 nicht produktiv einsetzbar sind. Die „aktiven Lösungswege" existieren für dieses Kernproblem bislang auf dem Papier, nicht im Einsatz.Substantiated: the capacity arithmetic is uncontested, and the article itself confirms that channel factories are not production-ready in 2026. For this core problem, the active solution paths exist on paper, not in deployment.Confirmado: la aritmética de capacidad es indiscutida, y el propio artículo confirma que las channel factories no están listas para producción en 2026. Para este problema central, las vías de solución activas existen sobre el papel, no en despliegue.Confirmado: a aritmética de capacidade é incontestada, e o próprio artigo confirma que as channel factories não estão prontas para produção em 2026. Para esse problema central, os caminhos de solução ativos existem no papel, não em operação.立証済み:容量の算術に争いはなく、Channel Factoriesが2026年時点で本番投入できないことは記事自身が認めている。この核心問題に対する「進行中の解決策」は、これまでのところ紙の上に存在するだけで、実運用には存在しない。成立:容量算术无可争议,文章自己也确认Channel Factories在2026年尚不能投入生产。对这一核心问题而言,「积极的解决路径」目前只存在于纸面,而非实际部署。مثبت: حسابات السعة لا خلاف عليها، ويؤكد المقال نفسه أن Channel Factories ليست جاهزة للإنتاج في 2026. وبالنسبة لهذه المشكلة الجوهرية، فإن مسارات الحل النشطة موجودة على الورق لا في التشغيل.
Die reale Marktantwort auf das Liquiditätsproblem ist nicht die im Artikel skizzierte Werkzeugpalette, sondern die Konzentration auf LSPs und custodiale Dienste – was genau die vom Artikel kritisierte Zentralisierung weiter vertieft.The market's actual answer to the liquidity problem is not the toolbox the article sketches, but concentration on LSPs and custodial services — which deepens exactly the centralization the article criticizes.La respuesta real del mercado al problema de liquidez no es la caja de herramientas que esboza el artículo, sino la concentración en LSP y servicios custodiales, lo que profundiza exactamente la centralización que el artículo critica.A resposta real do mercado ao problema de liquidez não é a caixa de ferramentas que o artigo esboça, mas a concentração em LSPs e serviços custodiais — o que aprofunda exatamente a centralização que o artigo critica.流動性問題への市場の実際の答えは、記事が描く道具立てではなく、LSPとカストディアルサービスへの集中である。それは記事が批判する中央集権化をまさに深化させている。市场对流动性问题的实际回答并不是文章勾勒的那套工具,而是向LSP和托管服务集中——这恰恰加深了文章所批评的中心化。جواب السوق الفعلي على مشكلة السيولة ليس عدة الأدوات التي يرسمها المقال، بل التركز في مزودي الخدمة والخدمات الوصائية — وهو ما يعمق تحديدا المركزية التي ينتقدها المقال.
Belegt: Liquidity Ads haben marginale Verbreitung, Channel Factories keine; das Onboarding läuft real über wenige LSPs (ACINQ u. a.) und custodiale Anbieter. Die Hub-Konzentration dokumentiert der Artikel selbst – die Lösungsansätze haben sie bislang nicht gebrochen.Substantiated: Liquidity Ads see marginal adoption, channel factories none; real-world onboarding runs through a few LSPs (ACINQ among others) and custodial providers. The article itself documents the hub concentration — the proposed remedies have not broken it so far.Confirmado: los Liquidity Ads tienen una adopción marginal y las channel factories ninguna; en la práctica, la incorporación pasa por unos pocos LSP (ACINQ, entre otros) y proveedores custodiales. El propio artículo documenta la concentración en hubs; los remedios propuestos no la han roto hasta ahora.Confirmado: Liquidity Ads têm adoção marginal e channel factories nenhuma; na prática, o onboarding passa por poucos LSPs (ACINQ, entre outros) e provedores custodiais. O próprio artigo documenta a concentração em hubs — os remédios propostos não a romperam até agora.立証済み:Liquidity Adsの普及は限定的で、Channel Factoriesは皆無。現実のオンボーディングは少数のLSP(ACINQなど)とカストディアル事業者を経由している。ハブ集中は記事自身が記録しており、提案された対策はこれまでそれを崩せていない。成立:Liquidity Ads普及有限,Channel Factories则为零;现实中的用户准入依赖少数LSP(如ACINQ)和托管服务商。文章自己就记录了枢纽集中现象——所提出的对策至今未能打破它。مثبت: انتشار Liquidity Ads هامشي وChannel Factories معدوم؛ ويجري الإدماج الفعلي عبر قلة من مزودي الخدمة (منهم ACINQ) ومزودين وصائيين. المقال نفسه يوثق تركز المحاور — والعلاجات المقترحة لم تكسره حتى الآن.
Die öffentlichen Kennzahlen deuten auf Stagnation statt Wachstum: rund 5.000 BTC Kapazität und seit dem Hoch von 2022 rückläufige öffentliche Kanalzahlen sprechen dafür, dass das Netzwerk ein Plateau erreicht hat.Public metrics point to stagnation rather than growth: roughly 5,000 BTC of capacity and public channel counts declining since the 2022 peak suggest the network has hit a plateau.Las métricas públicas apuntan a estancamiento más que a crecimiento: unos 5.000 BTC de capacidad y un número de canales públicos en descenso desde el máximo de 2022 sugieren que la red ha alcanzado una meseta.As métricas públicas apontam para estagnação, não crescimento: cerca de 5.000 BTC de capacidade e um número de canais públicos em queda desde o pico de 2022 sugerem que a rede atingiu um platô.公開指標は成長ではなく停滞を示している。約5,000 BTCの容量と、2022年のピーク以降減少している公開チャネル数は、ネットワークが頭打ちに達した可能性を示唆する。公开指标指向停滞而非增长:约5,000 BTC的容量,以及自2022年峰值以来不断下降的公开通道数,都表明网络可能已进入平台期。تشير المقاييس العامة إلى ركود لا نمو: فنحو 5,000 BTC من السعة وأعداد قنوات عامة متراجعة منذ ذروة 2022 توحي بأن الشبكة بلغت هضبة.
Offen: Die öffentlichen Kanäle fielen vom Hoch über 80.000 (2022) auf die im Artikel genannten 50.000–60.000 – doch private Kanäle und custodiale Volumina sind in öffentlichen Daten unsichtbar. Die reale Nutzung lässt sich damit in keine Richtung belastbar messen.Open: public channels fell from a peak above 80,000 (2022) to the 50,000-60,000 the article cites — but private channels and custodial volumes are invisible in public data. Real usage therefore cannot be measured reliably in either direction.Abierto: los canales públicos cayeron desde un máximo superior a 80.000 (2022) hasta los 50.000-60.000 que cita el artículo; pero los canales privados y los volúmenes custodiales son invisibles en los datos públicos. El uso real, por tanto, no puede medirse con fiabilidad en ninguna dirección.Em aberto: os canais públicos caíram de um pico acima de 80.000 (2022) para os 50.000-60.000 citados no artigo — mas canais privados e volumes custodiais são invisíveis nos dados públicos. O uso real, portanto, não pode ser medido com confiança em nenhuma direção.未確定:公開チャネルは80,000超のピーク(2022年)から記事が挙げる50,000〜60,000へ減少した。しかしプライベートチャネルとカストディアルの取引量は公開データには現れない。したがって実際の利用状況は、どちらの方向にも確実には測定できない。悬而未决:公开通道数从2022年逾80,000的峰值降至文章所引的50,000-60,000;但私有通道和托管交易量在公开数据中不可见。因此真实使用情况在任何方向上都无法可靠测量。مفتوح: تراجعت القنوات العامة من ذروة تفوق 80,000 (2022) إلى ما يذكره المقال من 50,000-60,000 — لكن القنوات الخاصة والأحجام الوصائية غير مرئية في البيانات العامة. لذا لا يمكن قياس الاستخدام الحقيقي بثقة في أي اتجاه.
QuellenSourcesFuentesFontes出典来源المصادر
- BOLT #2: Peer Protocol for Channel Management – Bitcoin Lightning RFC (github.com)
- BOLT #4: Onion Routing Protocol – Bitcoin Lightning RFC (github.com)
- mempool.space – Lightning Network Explorer (mempool.space)
- BLIP-0025: Trampoline Routing – Lightning BLIPs (github.com)
- ACINQ – Phoenix Wallet & Splicing Announcement (acinq.co)
- Bitcoin Lightning Network – bitcoin.org (bitcoin.org)