Lightning & SkalierungLightning & ScalingLightning & EscalabilidadLightning & EscalabilidadeLightning & スケーリングLightning & 扩容Lightning & التوسع
Lightning Network: Zahlungskanäle und Routing verständlich erklärtLightning Network: Payment Channels and Routing Clearly ExplainedRed de Relámpago: Canales de pago y enrutamiento explicados de manera clara y sencillaRede de Iluminação: Canais de pagamento e roteamento explicados de forma clara e compreensívelライトニング・ネットワーク: 支払いチャネルとルーティングがわかりやすく説明されますLighting Network: 轻松解释支付渠道和路由شبكة الضوء الساطع: قنوات الدفع و التوجيه توضيح باللغة العربية
Alle zentralen Fakten – 2-of-2 Multisig, Commitment Transactions, Revocation-Mechanismus, HTLCs, SPHINX/Onion Routing, CSV-Timelocks – sind im offiziellen Lightning-Whitepaper (Poon & Dryja), den BOLT-Spezifikationen und im Bitcoin-Wiki mehrfach unabhängig belegt. Netzwerkgrößenangaben (Stand 2026) als Schätzwerte aus mempool.space gekennzeichnet. Keine spekulativen oder unverifizierten Aussagen enthalten.All core facts – 2-of-2 multisig, Commitment Transactions, revocation mechanism, HTLCs, SPHINX/onion routing, CSV timelocks – are independently corroborated by the official Lightning whitepaper (Poon & Dryja), the BOLT specifications, and the Bitcoin Wiki. Network size figures (as of 2026) are flagged as estimates sourced from mempool.space. No speculative or unverified claims are included.Todas las facturas centrales – 2-of-2 Multisig, Transacciones de compromiso, Mecanismo de revocación, HTLCs, SPHINX/Enrutamiento de cebolla, Timelocks CSV – se encuentran en el whitepaper oficial de Lightning (Poon & Dryja), en las especificaciones BOLT y en el wiki de Bitcoin independientemente varias veces. Referencias a tamaños de red (2026) como valores estimados desde mempool.space. No contienen afirmaciones especulativas o no verificadas.Todas as factos centrais - 2-of-2 Multisig, Transações de Commitment, Mecanismo de Revogação, HTLCs, SPHINX/Onion Routing, CSV-Timelocks - estão comprovadas independentemente no whitepaper oficial Lightning (Poon & Dryja), nas especificações BOLT e no wiki Bitcoin. Valores estimados para tamanhos de rede (2026) marcados a partir de mempool.space. Nenhuma afirmação especulativa ou não verificada incluída.2-of-2 マルチシグ, コミットメントトランザクション, 反則機構, HTLCs, SPHINX/オニオンルーティング, CSVタイロック - これらは、Dryjaによる公式ライトニング・ホワイトペーパーとBOLT仕様書、およびビットコイン・ウィキで独立して複数回確認されています。2026年のネットワーク規模に関する記述(現状から推計)はmempool.spaceから示しています。これには、憶測や検証されていない主張が含まれていません。 & ビットコインのすべての中心的な事実 - 2-of-2 マルチシグ, コミットメントトランザクション, 反則機構, HTLCs, SPHINX/オニオンルーティング, CSVタイロック - は、Dryjaによる公式ライトニング・ホワイトペーパー(BOLT仕様書)およびビットコイン・ウィキで独立して複数回確認されています。ネットワーク規模に関する記述(2026年現在の推計値)はmempool.spaceから示しています。これには、憶測や検証されていない主張が含まれていません。所有中心事实 - 2-of-2 多签,承诺交易,撤销机制,HTLCs,SPHINX/洋葱路由,CSV时间锁 - 在官方Lightning白皮书(Poon Dryja)中、BOLT规范和Bitcoin维基百科中独立证实。网络大小说明(2026年数据)以mempool.space标记。没有进行猜测性的或未验证的声明。 & 仅包含事实,无任何主观判断。كل الحقائق المركزية - 2-of-2 Multisig، Transactions الملتزمة، نظام الغاء الاطلاق، HTLCs، SPHINX/Onion Routing، CSV-Timelocks - مدرجة بشكل مستقل في الوثائق الرسمية للنور (Poon & Dryja) والتفاصيل الفنية (BOLT-Spezifikationen) وفي ويكي البيتكوين. اعدادات حجم الشبكة (عام 2026) مكتوبة كأرقام تقريبية من موقع mempool.space. لا يحتوي هذا التقرير على ادعاءات خيالية أو غير محكمة.
Das Lightning Network bietet eindrucksvolle kryptographische Garantien auf dem Papier – doch die Praxis zeigt strukturelle Grenzen: SPHINX-Onion-Routing schützt nicht zuverlässig vor Timing-Korrelation und Channel-Probing-Angriffen, die Identität von Sender oder Empfänger können Angreifer dennoch erschließen. HTLCs sind zudem anfällig für sogenannte Griefing- und Stuck-Payment-Attacken, bei denen Mittel zeitweise blockiert werden, ohne dass der Artikel dies erwähnt. Der Revocation-Mechanismus gegen Betrug setzt voraus, dass der betroffene Knoten (oder ein Watchtower) zum richtigen Zeitpunkt online ist – eine Bedingung, die viele Privatanwender in der Praxis nicht erfüllen. Wer Lightning ernsthaft nutzt, muss diese Einschränkungen kennen.The Lightning Network offers impressive cryptographic guarantees on paper – but practice reveals structural limitations: SPHINX onion routing does not reliably protect against timing correlation and channel-probing attacks, which can still allow an attacker to infer sender or recipient identity. HTLCs are also vulnerable to so-called griefing and stuck-payment attacks, in which funds are temporarily locked without the article acknowledging this. The revocation mechanism against cheating requires the affected node (or a watchtower) to be online at the right moment – a condition many private users cannot reliably meet. Anyone using Lightning seriously needs to be aware of these constraints.La red Lightning ofrece garantías criptográficas impresionantes en papel, pero la práctica muestra límites estructurales: el onion-routing SPHINX no protege de manera confiable contra ataques de correlación temporal y Channel-Probing, los atacantes aún pueden descubrir la identidad del emisor o receptor. Además, las HTLC son vulnerables a ataques de "griefing" y pago bloqueado, sin que el artículo lo mencione. El mecanismo de revocación contra el fraude supone que el nodo afectado (o un watchtower) esté en línea en el momento adecuado - una condición que muchos usuarios finales no cumplen en la práctica. Quien utilice realmente Lightning, debe conocer estas restricciones.A rede Lightning oferece garantias criptográficas impressionantes no papel - mas a prática mostra limitações estruturais: o roteamento Sphinx-Onion não protege de forma confiável contra correlações de tempo e ataques de Channel-Probing, permitindo aos atacantes descobrir a identidade do remetente ou destinatário. As HTLCs são igualmente vulneráveis a ataques conhecidos como Griefing e Stuck Payment, nos quais os meios temporariamente ficam bloqueados, sem que o artigo mencione isto. O mecanismo de revogação contra fraude pressupõe que o nó afetado (ou um watchtower) esteja online no momento certo - uma condição que muitos usuários finais na prática não satisfazem. Quem usa Lightning seriamente, deve conhecer essas limitações.ライトニング・ネットワークは紙上で印象的な暗号学的保証を提供しますが、実践では構造的な制限が見られます: SPHINXオニオンルーティングはタイミング相関とチャンネルプロビング攻撃から保護していません、攻撃者はまだ送信者または受取人のアイデンティティを把握できます。HTLCはまた、グリーフィングおよびストック・ペイメント・アタックに脆弱であり、中間手段が一時的にブロックされることがあります(この記事ではその点は触れられていませんでした)。詐欺対策のレヴォーカションミーチャンは、影響されたノード(またはウォッチタワー)が適切なタイミングでオンラインである前提で動作します - これは多くの実用的な個人利用者が実践では達成できない条件です。ライトニングを本気で使う人は、これらの制限を知る必要があります。Lightning 网络在纸上提供了令人印象深刻的加密保证,但实践中显示出结构性局限性: SPHINX-Onion 路由无法充分保护 against timing correlation 和 channel probing attacks, attackers 仍然 可以 理解 发件人 或 收件人的身份。HTLCs 同时 对于 所谓 的 Griefing 和 Stuck-Payment attacks 是 易受攻击的, 中间时间 会暂时 被阻塞, 文章 没有提到这一点。对欺诈的撤销机制假设参与者 (或一个 Watchtower) 在正确的时间在线 - 这是一个许多实际使用 Lightning 的私人用户无法满足的条件。如果 serious 使用 Lightning, 你必须了解这些限制。يقدم شبكة الضوء الساطع تأمين كريبتوغرافي محضور رائع على الورق - لكن الممارسة تظهر حدود تركيبيه: روتنج SPHINX لا يحمي بشكل موثوق من التطابق الزمني والهجوم على قنوات، ويظل المهاجم قادرًا على استكشاف هويت المستخدم أو المتلقي. HTLCs حساسة أيضًا للانتحارات المعروفة باسم Griefing و Stuck Payment Attacks، حيث يتم حجز الوسط لفترات زمنية دون ذكر ذلك في المقال. آلية الاسترداد ضد الاحتيال تتطلب أن يكون النقطة المعنية (أو برج المراقبة) متصلًا في الوقت الصحيح - وهي شروط لا تتمكن العديد من المستخدمين الخاص في الممارسة العملية من تحقيقها. الذين يستخدمون Lightning على محملserious يجب عليهم تعرف هذه القيود.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Das Lightning Network ist ein Layer-2-Protokoll auf Bitcoin, das schnelle und kostengünstige Zahlungen ermöglicht, indem es den Großteil der Transaktionen außerhalb der Blockchain abwickelt. Anstatt für jede Zahlung eine On-Chain-Transaktion zu erstellen, öffnen zwei Parteien einen Zahlungskanal, tauschen darin beliebig viele Off-Chain-Zahlungen aus und schließen ihn mit einer einzigen Abrechnungstransaktion.
Kanalöffnung: Die Funding Transaction
Ein Lightning-Kanal entsteht durch eine On-Chain-Transaktion, die Bitcoin in einem gemeinsamen 2-of-2-Multisig-Output sperrt – der sogenannten Funding Transaction. Beide Parteien müssen gemeinsam signieren, um Mittel zu bewegen. Erst wenn diese Transaktion im Bitcoin-Netzwerk bestätigt ist, gilt der Kanal als geöffnet. Alle nachfolgenden Zahlungen innerhalb des Kanals sind Off-Chain: Sie werden in Millisekunden abgewickelt und verursachen nahezu keine Gebühren.
Commitment Transactions und der Revocation-Mechanismus
Der aktuelle Kanalstand wird durch Commitment Transactions abgebildet – vorbereitete, aber nicht veröffentlichte Transaktionen, die jederzeit on-chain eingereicht werden könnten. Bei jeder Zahlung erstellen beide Parteien eine neue Commitment Transaction und machen die vorherige ungültig, indem sie sich gegenseitig den zugehörigen Revocation Key übergeben.
Wer einen alten, bereits ungültigen Kanalstand on-chain einreicht, riskiert, sein gesamtes Kanalvermögen zu verlieren: Der ehrliche Partner kann mit dem Revocation Key innerhalb eines Timelocks das komplette Guthaben einfordern. Betrug lohnt sich schlicht nicht – ein klassisches spieltheoretisches Gleichgewicht.
Kanalschluss: Kooperativ oder unilateral
Ein Kanal kann auf zwei Wegen geschlossen werden:
- Mutual Close (kooperativ): Beide Parteien signieren gemeinsam eine Closing Transaction, die den aktuellen Kanalstand sofort on-chain auszahlt. Günstig, schnell und bevorzugt.
- Force Close (unilateral): Eine Partei veröffentlicht einseitig die letzte Commitment Transaction. Der schließende Peer muss dabei einen Timelock via CheckSequenceVerify (CSV) abwarten – typischerweise 144 bis 2.016 Blöcke, entsprechend etwa 1 bis 14 Tagen (Stand 2026). Dieser Zeitraum gibt dem Gegenüber Gelegenheit, auf etwaigen Betrug zu reagieren.
Multi-Hop-Zahlungen und HTLCs
Die eigentliche Stärke des Lightning Network liegt darin, dass Zahlungen nicht nur zwischen direkt verbundenen Parteien, sondern durch das gesamte Netzwerk geroutet werden können. Das Schlüsselinstrument dafür sind Hash Time-Locked Contracts (HTLCs).
Funktionsprinzip: Der Empfänger erzeugt ein geheimes Preimage und gibt dessen kryptographischen Hash an den Sender weiter. Der Sender sperrt Mittel entlang der Route konditionell: Jeder Hop gibt das Geld erst frei, wenn das korrekte Preimage vorgelegt wird. Kann das Preimage nicht rechtzeitig vorgelegt werden, läuft der Timelock ab und alle gesperrten Mittel werden zurückgegeben.
HTLCs sind atomar: Entweder wird die Zahlung über alle Hops hinweg vollständig abgewickelt, oder keine einzige Partei auf dem Pfad verliert Geld. Es gibt kein partielles Scheitern auf Kosten Dritter.
Die Timelocks der HTLCs sind gestaffelt: Jeder Hop erhält weniger Zeit als der vorherige (CLTV Delta, typisch 40–144 Blöcke pro Hop, Stand 2026), damit kein Zwischenhändler durch Verzögerung einen Vorteil erlangen kann.
Onion Routing (SPHINX): Privatsphäre by Design
Das Routing im Lightning Network basiert auf dem SPHINX-Protokoll, einer Form des Onion Routings. Die Zahlungsinformation wird in verschachtelte Verschlüsselungsschichten verpackt: Jeder Knoten kann nur seinen unmittelbaren Vorgänger und Nachfolger identifizieren – weder Quelle noch Ziel der Zahlung sind einem einzelnen Hop bekannt. Privatsphäre ist damit kein nachträgliches Feature, sondern strukturell im Protokoll verankert.
Liquidität: Die praktische Herausforderung
Routing setzt voraus, dass jeder Hop auf dem Pfad ausreichend Liquidität in der richtigen Richtung bereitstellt. Man unterscheidet Outbound Liquidity (Mittel, die man senden kann) und Inbound Liquidity (Mittel, die man empfangen kann). Ein Knoten kann nur so viel routen, wie sein engster Flaschenhals erlaubt.
Stand 2026 umfasst das öffentliche Lightning-Netzwerk rund 12.000–15.000 Nodes und 50.000–60.000 öffentliche Kanäle. Das Liquiditätsmanagement – etwa durch Channel Rebalancing oder Dienste wie Liquidity Ads – ist die zentrale operative Herausforderung für Knotenbetreiende.
Fazit
Das Lightning Network löst Bitcoins Skalierungsproblem durch ein elegantes Zusammenspiel von kryptographischen Primitiven: Multisig-Sperrung, Commitment Transactions mit Revocation-Mechanismus, atomare HTLCs und privates Onion Routing. Der Preis für Sofortzahlungen ist aktives Liquiditätsmanagement – ein Kompromiss, der das Protokoll zu einem der technisch anspruchsvollsten, aber auch leistungsfähigsten Bausteine des Bitcoin-Ökosystems macht.
Weiterführend
The Lightning Network is a Layer-2 protocol built on Bitcoin that enables fast, low-cost payments by handling the vast majority of transactions off-chain. Rather than creating a Bitcoin transaction for every payment, two parties open a payment channel, exchange any number of off-chain payments within it, and close it with a single settlement transaction.
Opening a Channel: The Funding Transaction
A Lightning channel is created by an on-chain transaction that locks bitcoin into a shared 2-of-2 multisig output – the so-called Funding Transaction. Both parties must sign jointly to move funds. Only once this transaction is confirmed on the Bitcoin network is the channel considered open. All subsequent payments within the channel are off-chain: they settle in milliseconds and incur virtually no fees.
Commitment Transactions and the Revocation Mechanism
The current channel balance is represented by Commitment Transactions – pre-signed but unpublished transactions that could be broadcast on-chain at any time. With each payment, both parties create a new Commitment Transaction and invalidate the previous one by exchanging the corresponding Revocation Key.
Anyone who broadcasts an old, already-invalidated channel state on-chain risks losing their entire channel balance: the honest counterparty can use the Revocation Key to claim all funds within a timelock window. Cheating simply doesn't pay – a classic game-theoretic equilibrium.
Closing a Channel: Cooperative or Unilateral
A channel can be closed in two ways:
- Mutual Close (cooperative): Both parties co-sign a Closing Transaction that immediately settles the current channel balance on-chain. Fast, cheap, and the preferred method.
- Force Close (unilateral): One party broadcasts their latest Commitment Transaction unilaterally. The closing peer must then wait out a timelock enforced via CheckSequenceVerify (CSV) – typically 144 to 2,016 blocks, roughly 1 to 14 days (as of 2026). This window gives the counterparty time to respond to any attempted fraud.
Multi-Hop Payments and HTLCs
The true power of the Lightning Network lies in its ability to route payments not just between directly connected parties, but across the entire network. The key instrument for this is Hash Time-Locked Contracts (HTLCs).
How it works: the recipient generates a secret preimage and shares its cryptographic hash with the sender. The sender conditionally locks funds along the route: each hop releases the funds only upon presentation of the correct preimage. If the preimage cannot be presented in time, the timelock expires and all locked funds are returned.
HTLCs are atomic: either the payment completes fully across all hops, or no party on the path loses any money. There is no partial failure at the expense of third parties.
HTLC timelocks are staggered: each hop receives less time than the previous one (CLTV delta, typically 40–144 blocks per hop as of 2026), ensuring no intermediary can gain an advantage through deliberate delay.
Onion Routing (SPHINX): Privacy by Design
Routing in the Lightning Network is based on the SPHINX protocol, a form of onion routing. Payment information is wrapped in nested layers of encryption: each node can only identify its immediate predecessor and successor – neither the source nor the destination of the payment is known to any single hop. Privacy is therefore not a bolt-on feature but is structurally embedded in the protocol.
Liquidity: The Practical Challenge
Routing requires that every hop on a path provide sufficient liquidity in the right direction. A distinction is made between outbound liquidity (funds available to send) and inbound liquidity (capacity to receive). A node can only route as much as its tightest bottleneck allows.
As of 2026, the public Lightning Network comprises approximately 12,000–15,000 nodes and 50,000–60,000 public channels. Liquidity management – through channel rebalancing or services like Liquidity Ads – is the central operational challenge for node operators.
Conclusion
The Lightning Network addresses Bitcoin's scaling problem through an elegant interplay of cryptographic primitives: multisig locking, Commitment Transactions with a revocation mechanism, atomic HTLCs, and private onion routing. The trade-off for instant payments is active liquidity management – a compromise that makes this protocol one of the most technically sophisticated and capable building blocks in the Bitcoin ecosystem.
Related
Lightning Network es un protocolo de capa 2 sobre Bitcoin que permite pagos rápidos y de bajo costo al gestionar la gran mayoría de las transacciones fuera de la cadena. En lugar de crear una transacción on-chain por cada pago, dos partes abren un canal de pago, intercambian dentro de él cualquier número de pagos off-chain y lo cierran con una única transacción de liquidación.
Apertura de un canal: la Funding Transaction
Un canal Lightning se crea mediante una transacción on-chain que bloquea bitcoin en un output multisig 2-de-2 compartido, la denominada Funding Transaction. Ambas partes deben firmar conjuntamente para mover fondos. El canal solo se considera abierto una vez que esta transacción ha sido confirmada en la red Bitcoin. Todos los pagos posteriores dentro del canal son off-chain: se liquidan en milisegundos y generan prácticamente cero comisiones.
Commitment Transactions y el mecanismo de revocación
El estado actual del canal se representa mediante Commitment Transactions: transacciones prefirmadas pero no publicadas que podrían transmitirse on-chain en cualquier momento. Con cada pago, ambas partes crean una nueva Commitment Transaction e invalidan la anterior intercambiándose mutuamente la correspondiente Revocation Key.
Quien transmita on-chain un estado de canal antiguo y ya invalidado se arriesga a perder todo su saldo en el canal: la contraparte honesta puede utilizar la Revocation Key para reclamar la totalidad de los fondos dentro de la ventana del timelock. Hacer trampa sencillamente no compensa: un clásico equilibrio de la teoría de juegos.
Cierre de un canal: cooperativo o unilateral
Un canal puede cerrarse de dos maneras:
- Mutual Close (cooperativo): Ambas partes firman conjuntamente una Closing Transaction que liquida de inmediato el saldo actual del canal on-chain. Económico, rápido y el método preferido.
- Force Close (unilateral): Una parte transmite unilateralmente su última Commitment Transaction. El nodo que cierra debe esperar un timelock aplicado mediante CheckSequenceVerify (CSV), típicamente entre 144 y 2.016 bloques, lo que equivale a aproximadamente 1 y 14 días (a partir de 2026). Esta ventana le da tiempo a la contraparte para reaccionar ante cualquier intento de fraude.
Pagos multi-salto y HTLCs
La verdadera fortaleza de Lightning Network reside en su capacidad para enrutar pagos no solo entre partes directamente conectadas, sino a través de toda la red. El instrumento clave para ello son los Hash Time-Locked Contracts (HTLCs).
Funcionamiento: el receptor genera un preimage secreto y comparte su hash criptográfico con el emisor. El emisor bloquea fondos condicionalmente a lo largo de la ruta: cada salto libera los fondos únicamente al presentar el preimage correcto. Si el preimage no puede presentarse a tiempo, el timelock expira y todos los fondos bloqueados son devueltos.
Los HTLCs son atómicos: o el pago se completa íntegramente a través de todos los saltos, o ninguna parte de la ruta pierde dinero. No existe un fallo parcial a costa de terceros.
Los timelocks de los HTLCs son escalonados: cada salto dispone de menos tiempo que el anterior (CLTV delta, típicamente 40–144 bloques por salto, a partir de 2026), de modo que ningún intermediario pueda obtener ventaja mediante retrasos deliberados.
Onion Routing (SPHINX): privacidad por diseño
El enrutamiento en Lightning Network se basa en el protocolo SPHINX, una forma de onion routing. La información del pago se envuelve en capas de cifrado anidadas: cada nodo solo puede identificar a su predecesor y sucesor inmediatos; ni el origen ni el destino del pago son conocidos por ningún salto individual. La privacidad no es, por tanto, una función añadida a posteriori, sino que está estructuralmente integrada en el protocolo.
Liquidez: el desafío práctico
El enrutamiento exige que cada salto en la ruta disponga de liquidez suficiente en la dirección correcta. Se distingue entre liquidez de salida (fondos disponibles para enviar) y liquidez de entrada (capacidad para recibir). Un nodo solo puede enrutar tanto como permita su cuello de botella más estrecho.
A partir de 2026, la red Lightning pública comprende aproximadamente 12.000–15.000 nodos y 50.000–60.000 canales públicos. La gestión de liquidez, ya sea mediante el reequilibrio de canales o servicios como Liquidity Ads, es el principal desafío operativo para los operadores de nodos.
Conclusión
Lightning Network resuelve el problema de escalabilidad de Bitcoin mediante una elegante combinación de primitivas criptográficas: bloqueo multisig, Commitment Transactions con mecanismo de revocación, HTLCs atómicos y onion routing privado. El precio de los pagos instantáneos es una gestión activa de la liquidez: un compromiso que convierte a este protocolo en uno de los componentes técnicamente más sofisticados y potentes del ecosistema Bitcoin.
Más información
O Lightning Network é um protocolo de Layer 2 construído sobre o Bitcoin que permite pagamentos rápidos e de baixo custo, processando a grande maioria das transações fora da blockchain. Em vez de criar uma transação on-chain para cada pagamento, duas partes abrem um canal de pagamento, trocam quantos pagamentos off-chain quiserem dentro dele e o encerram com uma única transação de liquidação.
Abertura de Canal: A Funding Transaction
Um canal Lightning é criado por uma transação on-chain que bloqueia bitcoin em um output multisig 2-de-2 compartilhado – a chamada Funding Transaction. Ambas as partes precisam assinar conjuntamente para movimentar os fundos. O canal só é considerado aberto após essa transação ser confirmada na rede Bitcoin. Todos os pagamentos subsequentes dentro do canal são off-chain: são liquidados em milissegundos e praticamente não geram taxas.
Commitment Transactions e o Mecanismo de Revogação
O saldo atual do canal é representado pelas Commitment Transactions – transações pré-assinadas, mas não publicadas, que poderiam ser transmitidas on-chain a qualquer momento. A cada pagamento, ambas as partes criam uma nova Commitment Transaction e invalidam a anterior, trocando entre si a Revocation Key correspondente.
Quem transmitir on-chain um estado de canal antigo e já invalidado arrisca perder todo o seu saldo no canal: a contraparte honesta pode usar a Revocation Key para reivindicar todos os fundos dentro da janela de timelock. Simplesmente não compensa trapacear – um equilíbrio clássico da teoria dos jogos.
Encerramento de Canal: Cooperativo ou Unilateral
Um canal pode ser encerrado de duas formas:
- Mutual Close (cooperativo): Ambas as partes co-assinam uma Closing Transaction que liquida imediatamente o saldo atual do canal on-chain. Rápido, barato e o método preferido.
- Force Close (unilateral): Uma das partes transmite unilateralmente a sua última Commitment Transaction. O peer que encerra o canal deve então aguardar um timelock imposto via CheckSequenceVerify (CSV) – tipicamente de 144 a 2.016 blocos, correspondendo a cerca de 1 a 14 dias (em 2026). Essa janela dá à contraparte tempo para reagir a qualquer tentativa de fraude.
Pagamentos Multi-Hop e HTLCs
O verdadeiro poder do Lightning Network reside na sua capacidade de rotear pagamentos não apenas entre partes diretamente conectadas, mas por toda a rede. O instrumento-chave para isso são os Hash Time-Locked Contracts (HTLCs).
Como funciona: o destinatário gera um preimage secreto e compartilha o seu hash criptográfico com o remetente. O remetente bloqueia fundos condicionalmente ao longo da rota: cada hop libera os fundos somente mediante a apresentação do preimage correto. Se o preimage não puder ser apresentado a tempo, o timelock expira e todos os fundos bloqueados são devolvidos.
Os HTLCs são atômicos: ou o pagamento é concluído integralmente por todos os hops, ou nenhuma parte no caminho perde dinheiro. Não existe falha parcial às custas de terceiros.
Os timelocks dos HTLCs são escalonados: cada hop recebe menos tempo do que o anterior (CLTV delta, tipicamente 40–144 blocos por hop em 2026), garantindo que nenhum intermediário possa obter vantagem por meio de atrasos deliberados.
Onion Routing (SPHINX): Privacidade por Design
O roteamento no Lightning Network é baseado no protocolo SPHINX, uma forma de onion routing. As informações de pagamento são encapsuladas em camadas aninhadas de criptografia: cada nó consegue identificar apenas o seu predecessor e sucessor imediatos – nem a origem nem o destino do pagamento são conhecidos por qualquer hop individualmente. A privacidade, portanto, não é um recurso adicionado posteriormente, mas está estruturalmente incorporada ao protocolo.
Liquidez: O Desafio Prático
O roteamento exige que cada hop no caminho disponibilize liquidez suficiente na direção correta. Distingue-se entre outbound liquidity (fundos disponíveis para enviar) e inbound liquidity (capacidade de receber). Um nó só consegue rotear tanto quanto o seu gargalo mais estreito permitir.
Em 2026, o Lightning Network público compreende aproximadamente 12.000–15.000 nós e 50.000–60.000 canais públicos. O gerenciamento de liquidez – por meio de rebalanceamento de canais ou serviços como Liquidity Ads – é o principal desafio operacional para os operadores de nós.
Conclusão
O Lightning Network resolve o problema de escalabilidade do Bitcoin por meio de uma interação elegante de primitivas criptográficas: bloqueio multisig, Commitment Transactions com mecanismo de revogação, HTLCs atômicos e onion routing privado. O trade-off pelos pagamentos instantâneos é o gerenciamento ativo de liquidez – um compromisso que torna este protocolo um dos blocos de construção mais tecnicamente sofisticados e poderosos do ecossistema Bitcoin.
Mais informação
Lightning Networkは、Bitcoin上に構築されたLayer-2プロトコルであり、取引の大部分をオフチェーンで処理することで、高速かつ低コストの決済を実現します。支払いのたびにオンチェーントランザクションを作成するのではなく、2者間で支払いチャネルを開設し、その中で任意の回数のオフチェーン決済をやり取りした後、単一の清算トランザクションでチャネルを閉じます。
チャネルの開設:Funding Transaction
Lightningチャネルは、Bitcoin を共有の2-of-2マルチシグ出力にロックするオンチェーントランザクション、すなわちFunding Transactionによって作成されます。資金を移動するには、両者が共同で署名する必要があります。このトランザクションがBitcoinネットワークで承認されて初めて、チャネルが開設されたとみなされます。チャネル内のその後の支払いはすべてオフチェーンで行われ、ミリ秒単位で決済され、手数料はほぼ発生しません。
Commitment TransactionとRevocationメカニズム
現在のチャネル残高はCommitment Transactionによって表現されます。これは事前に署名されているが未公開のトランザクションであり、いつでもオンチェーンにブロードキャストできます。支払いのたびに、両者は新しいCommitment Transactionを作成し、対応するRevocation Keyを互いに渡すことで、前のトランザクションを無効化します。
すでに無効化された古いチャネル状態をオンチェーンにブロードキャストした者は、チャネル残高全額を失うリスクを負います。正直な相手方はRevocation Keyを使い、タイムロックの期間内にすべての資金を請求できます。不正行為は割に合わない——これはゲーム理論における古典的な均衡です。
チャネルのクローズ:協調的または一方的
チャネルは2通りの方法で閉じることができます:
- Mutual Close(協調的クローズ):両者が共同でClosing Transactionに署名し、現在のチャネル残高を即座にオンチェーンで精算します。安価で高速かつ推奨される方法です。
- Force Close(一方的クローズ):一方の当事者が最新のCommitment Transactionを一方的にブロードキャストします。クローズを行うピアは、CheckSequenceVerify(CSV)によるタイムロックを待機する必要があります。通常144〜2,016ブロック、約1〜14日間(2026年時点)です。この期間により、相手方は不正行為が試みられた場合に対応する機会が与えられます。
マルチホップ決済とHTLC
Lightning Networkの真の強みは、直接接続された当事者間だけでなく、ネットワーク全体を経由して支払いをルーティングできる点にあります。その中心的な仕組みがHash Time-Locked Contracts(HTLC)です。
仕組み:受取人は秘密のプレイメージ(preimage)を生成し、その暗号学的ハッシュを送信者に渡します。送信者はルート上で条件付きに資金をロックします。各ホップは、正しいpreimageが提示された場合にのみ資金を解放します。期限内にpreimageが提示されなければ、タイムロックが満了し、ロックされた資金はすべて返還されます。
HTLCはアトミックです。すべてのホップを通じて支払いが完全に完了するか、あるいはパス上のいかなる当事者も損失を被らないか、どちらかです。第三者の犠牲による部分的な失敗は起こりません。
HTLCのタイムロックは段階的に設定されています。各ホップは前のホップよりも短い時間しか与えられません(CLTVデルタ、2026年時点で通常ホップあたり40〜144ブロック)。これにより、中間ノードが意図的な遅延によって利益を得ることを防ぎます。
Onion Routing(SPHINX):設計によるプライバシー
Lightning Networkのルーティングは、Onion Routingの一形態であるSPHINXプロトコルに基づいています。支払い情報は多層の暗号化に包まれており、各ノードは直前と直後のノードしか識別できません。支払いの送信元も宛先も、単一のホップには知られません。プライバシーは後付けの機能ではなく、プロトコルの構造に組み込まれています。
流動性:実践的な課題
ルーティングには、パス上のすべてのホップが正しい方向に十分な流動性を提供していることが必要です。アウトバウンド流動性(送信可能な資金)とインバウンド流動性(受信可能な容量)が区別されます。ノードがルーティングできる量は、最も狭いボトルネックによって制限されます。
2026年時点で、公開Lightning Networkは約12,000〜15,000ノード、50,000〜60,000の公開チャネルで構成されています。チャネルのリバランスやLiquidity Adsなどのサービスを通じた流動性管理は、ノード運営者にとって中心的な運用上の課題です。
まとめ
Lightning Networkは、暗号学的プリミティブの巧みな組み合わせによってBitcoinのスケーリング問題に対処しています。その要素は、マルチシグによるロック、Revocationメカニズムを備えたCommitment Transaction、アトミックなHTLC、そしてプライベートなOnion Routingです。即時決済のトレードオフは積極的な流動性管理であり、このプロトコルをBitcoinエコシステムにおいて最も技術的に高度で、かつ強力な構成要素の一つにしています。
関連情報
Lightning Network 是构建于 Bitcoin 之上的二层协议,通过将绝大多数交易放在链下处理,实现快速、低成本的支付。双方无需为每笔付款创建一笔链上交易,而是开启一条支付通道,在通道内进行任意次数的链下支付,最后以一笔结算交易关闭通道。
开启通道:资金交易(Funding Transaction)
Lightning 通道由一笔链上交易创建,该交易将 Bitcoin 锁定在一个共同的 2-of-2 多签输出中——即所谓的 Funding Transaction。双方必须联合签名才能动用资金。只有当这笔交易在 Bitcoin 网络上得到确认,通道才被视为正式开启。通道内的所有后续支付均为链下操作:在毫秒内完成结算,几乎不产生任何手续费。
承诺交易与撤销机制(Commitment Transactions & Revocation)
当前通道余额由 Commitment Transactions(承诺交易)表示——这些交易已预先签名但尚未广播,随时可以提交至链上。每完成一笔支付,双方就创建一笔新的 Commitment Transaction,并通过互相交换对应的 Revocation Key(撤销密钥)使上一笔承诺交易作废。
任何人若将已作废的旧通道状态广播至链上,都将面临损失全部通道资金的风险:诚实的对手方可凭借 Revocation Key 在时间锁窗口内索取全部余额。欺诈根本无利可图——这是一个经典的博弈论均衡。
关闭通道:协作关闭或单方关闭
通道可通过两种方式关闭:
- Mutual Close(协作关闭):双方共同签署一笔 Closing Transaction,立即将当前通道余额结算至链上。经济、快速,是首选方式。
- Force Close(单方强制关闭):一方单方面广播最新的 Commitment Transaction。发起关闭的一方必须等待 通过 CheckSequenceVerify(CSV)强制执行的时间锁——通常为 144 至 2,016 个区块,约合 1 至 14 天(截至 2026 年)。此等待期为对手方提供了应对潜在欺诈的时间。
多跳支付与 HTLC
Lightning Network 的真正威力在于,支付不仅可以在直接相连的双方之间进行,还能通过整个网络进行路由。实现这一功能的核心工具是 哈希时间锁合约(Hash Time-Locked Contracts,HTLCs)。
工作原理:收款方生成一个秘密的 Preimage,并将其密码学哈希值告知付款方。付款方沿路由有条件地锁定资金:每一跳只有在收到正确的 Preimage 后才会释放资金。若 Preimage 未能在规定时间内提交,时间锁到期,所有被锁定的资金将原路退回。
HTLC 具有原子性:要么支付在所有跳点上完整完成,要么路径上的任何一方都不会损失资金。不存在以牺牲第三方为代价的部分失败情形。
HTLC 的时间锁采用递减设计:每一跳获得的时间均少于前一跳(CLTV Delta,截至 2026 年每跳通常为 40–144 个区块),确保任何中间节点都无法通过蓄意延迟获取优势。
洋葱路由(SPHINX):隐私原生设计
Lightning Network 的路由基于 SPHINX 协议,这是一种洋葱路由形式。支付信息被层层嵌套的加密层包裹:每个节点只能识别其直接前驱和后继节点——任何单一跳点既不知道支付的来源,也不知道支付的目的地。因此,隐私保护并非事后附加的功能,而是在协议层面进行了结构性内嵌。
流动性:现实挑战
路由要求路径上的每一跳都能在正确方向上提供充足的流动性。需要区分 出站流动性(Outbound Liquidity)(可发送的资金)与 入站流动性(Inbound Liquidity)(可接收的容量)。节点的路由能力受限于其最窄的瓶颈通道。
截至 2026 年,公开的 Lightning Network 约有 12,000–15,000 个节点和 50,000–60,000 条公开通道。流动性管理——例如通道再平衡或 Liquidity Ads 等服务——是节点运营者面临的核心运营挑战。
总结
Lightning Network 通过密码学原语的优雅组合解决了 Bitcoin 的扩容难题:多签锁定、带撤销机制的 Commitment Transactions、原子性 HTLC 以及私密洋葱路由。即时支付的代价是主动的流动性管理——正是这一权衡,使该协议成为 Bitcoin 生态系统中技术上最为精密、也最具实力的基础构件之一。
延伸阅读
شبكة Lightning Network هي بروتوكول من الطبقة الثانية (Layer-2) مبنيٌّ على Bitcoin، يتيح إجراء مدفوعات سريعة وبتكلفة منخفضة من خلال معالجة الغالبية العظمى من المعاملات خارج السلسلة (off-chain). بدلاً من إنشاء معاملة Bitcoin لكل دفعة، تفتح الجهتان قناة دفع، وتتبادلان عبرها أي عدد من المدفوعات خارج السلسلة، ثم تغلقانها بمعاملة تسوية واحدة.
فتح القناة: معاملة التمويل (Funding Transaction)
تُنشأ قناة Lightning بمعاملة على السلسلة (on-chain) تقوم بتأمين Bitcoin في مخرج 2-of-2 Multisig مشترك – وهو ما يُعرف بمعاملة التمويل (Funding Transaction). يجب على الطرفين التوقيع معاً لتحريك الأموال. ولا تُعدّ القناة مفتوحة إلا بعد تأكيد هذه المعاملة على شبكة Bitcoin. جميع المدفوعات اللاحقة داخل القناة تتم خارج السلسلة: تُسوَّى في أجزاء من الثانية وتكاد لا تُكبِّد أي رسوم.
معاملات الالتزام (Commitment Transactions) وآلية الإلغاء (Revocation)
يُمثَّل الرصيد الحالي للقناة من خلال معاملات الالتزام (Commitment Transactions) – وهي معاملات موقَّعة مسبقاً لكنها غير منشورة، ويمكن بثّها على السلسلة في أي وقت. مع كل دفعة، يُنشئ الطرفان معاملة التزام جديدة ويُبطلان السابقة عبر تبادل مفتاح الإلغاء (Revocation Key) المقابل.
من يبثّ على السلسلة حالةَ قناة قديمة وملغاة يخاطر بخسارة رصيده بالكامل في القناة: إذ يمكن للطرف الأمين استخدام مفتاح الإلغاء (Revocation Key) لاسترداد جميع الأموال خلال نافذة الـ Timelock. الغش ببساطة لا يُجدي نفعاً – وهو توازن كلاسيكي من نظرية الألعاب.
إغلاق القناة: تعاوني أم أحادي الجانب
يمكن إغلاق القناة بطريقتين:
- Mutual Close (تعاوني): يوقّع الطرفان معاً على معاملة إغلاق (Closing Transaction) تُسوّي الرصيد الحالي للقناة فوراً على السلسلة. سريع وقليل التكلفة وهو الأسلوب المفضّل.
- Force Close (أحادي الجانب): يبثّ أحد الطرفين منفرداً آخر معاملة التزام لديه. يتعيّن على الطرف المغلِق انتظار Timelock المُفعَّل عبر CheckSequenceVerify (CSV) – يبلغ عادةً من 144 إلى 2,016 كتلة، أي ما يعادل نحو 1 إلى 14 يوماً (اعتباراً من عام 2026). تمنح هذه النافذة الطرفَ الآخر الوقتَ الكافي للاستجابة في حال وقوع أي محاولة احتيال.
المدفوعات متعددة القفزات (Multi-Hop) وعقود HTLCs
تكمن القوة الحقيقية لشبكة Lightning Network في قدرتها على توجيه المدفوعات ليس فقط بين الأطراف المتصلة مباشرةً، بل عبر الشبكة بأكملها. والأداة المحورية لتحقيق ذلك هي عقود Hash Time-Locked Contracts (HTLCs).
آلية العمل: يُنشئ المستلم preimage سرياً ويُشارك الهاش التشفيري الخاص به مع المُرسِل. يقوم المُرسِل بتأمين الأموال بصورة مشروطة على طول المسار: لا تُحرَّر الأموال في كل قفزة إلا عند تقديم الـ preimage الصحيح. وإن تعذّر تقديم الـ preimage في الوقت المحدد، تنتهي مهلة الـ Timelock وتُعاد جميع الأموال المحتجزة.
عقود HTLCs ذرية (atomic): إما أن تكتمل الدفعة بالكامل عبر جميع القفزات، أو لا يخسر أي طرف على المسار شيئاً. لا يوجد فشل جزئي على حساب أطراف أخرى.
مُهل الـ Timelock في عقود HTLCs متدرجة: تحصل كل قفزة على وقت أقل من سابقتها (CLTV Delta، يبلغ عادةً 40–144 كتلة لكل قفزة، اعتباراً من عام 2026)، مما يضمن عدم قدرة أي وسيط على الاستفادة من التأخير المتعمد.
التوجيه عبر البصل (SPHINX): الخصوصية بالتصميم
يعتمد التوجيه في شبكة Lightning Network على بروتوكول SPHINX، وهو شكل من أشكال التوجيه البصلي (Onion Routing). تُغلَّف معلومات الدفع في طبقات متداخلة من التشفير: لا يستطيع كل عقدة سوى التعرف على العقدة السابقة والتالية لها مباشرةً – ولا تعلم أي قفزة منفردة بمصدر الدفعة أو وجهتها. وهكذا فإن الخصوصية ليست ميزة مُضافة لاحقاً، بل هي مُدمجة هيكلياً في البروتوكول.
السيولة: التحدي العملي
يشترط التوجيه أن توفر كل قفزة على المسار سيولةً كافية في الاتجاه الصحيح. يُميَّز بين السيولة الصادرة (Outbound Liquidity) (الأموال المتاحة للإرسال) والسيولة الواردة (Inbound Liquidity) (الطاقة الاستيعابية للاستقبال). لا تستطيع العقدة توجيه أكثر مما يسمح به أضيق عنق زجاجة لديها.
اعتباراً من عام 2026، تضم شبكة Lightning Network العامة نحو 12,000–15,000 عقدة و50,000–60,000 قناة عامة. تُعدّ إدارة السيولة – سواء عبر إعادة توازن القنوات (Channel Rebalancing) أو خدمات مثل Liquidity Ads – التحدي التشغيلي المحوري لمشغّلي العقد.
خلاصة
تعالج شبكة Lightning Network مشكلة التوسّع في Bitcoin من خلال تناغم أنيق بين العناصر التشفيرية الأساسية: التأمين عبر Multisig، ومعاملات الالتزام (Commitment Transactions) مع آلية الإلغاء، وعقود HTLCs الذرية، والتوجيه البصلي الخاص. والثمن مقابل المدفوعات الفورية هو إدارة السيولة النشطة – وهو تنازل يجعل هذا البروتوكول أحد أكثر اللبنات الأساسية تطوراً تقنياً وأعلاها كفاءة في منظومة Bitcoin.
مزيد من المعلومات
⚖️ 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.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定,绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
„Privatsphäre by Design" ist überzeichnet: Timing-Korrelation, Channel-Probing und der bis heute route-weit identische Payment-Hash erlauben Angreifern, die mehrere Nodes kontrollieren, die Deanonymisierung von Zahlungen – trotz SPHINX.Privacy by design is overstated: timing correlation, channel probing, and the payment hash that is still identical along the whole route allow adversaries controlling several nodes to deanonymize payments — despite SPHINX.La privacidad por diseño está sobredimensionada: la correlación temporal, el channel probing y el payment hash, que sigue siendo idéntico en toda la ruta, permiten a adversarios que controlan varios nodos desanonimizar pagos, pese a SPHINX.A privacidade por design está superdimensionada: correlação temporal, channel probing e o payment hash, ainda idêntico ao longo de toda a rota, permitem que adversários controlando vários nodes desanonimizem pagamentos — apesar do SPHINX.「設計段階からのプライバシー」は誇張である。タイミング相関、チャネル・プロービング、そして現在もルート全体で同一のペイメントハッシュにより、複数のノードを支配する攻撃者はSPHINXにもかかわらず支払いを非匿名化できる。「隐私内建于设计」言过其实:时序关联、通道探测,以及至今在整条路由上完全相同的支付哈希,让控制多个节点的攻击者即便面对SPHINX也能对支付去匿名化。مقولة الخصوصية بحكم التصميم مبالغ فيها: فالارتباط الزمني وسبر القنوات وتطابق تجزئة الدفع على طول المسار حتى اليوم تتيح لمهاجم يسيطر على عدة عقد كشف هوية المدفوعات — رغم SPHINX.
Belegt: Empirische Studien zur Lightning-Privatsphäre und dokumentierte Probing-Angriffe zur Balance-Ermittlung zeigen diese Vektoren; die geteilte Preimage-Schwäche ist zudem die von den Entwicklern selbst erklärte Motivation für den PTLC-Übergang.Substantiated: empirical studies of Lightning privacy and documented probing attacks for balance discovery demonstrate these vectors; the shared-preimage weakness is, moreover, the developers' own stated motivation for the PTLC transition.Confirmado: estudios empíricos sobre la privacidad de Lightning y ataques de probing documentados para descubrir balances demuestran estos vectores; la debilidad del preimage compartido es, además, la motivación declarada por los propios desarrolladores para la transición a PTLC.Confirmado: estudos empíricos sobre a privacidade do Lightning e ataques de probing documentados para descoberta de saldos demonstram esses vetores; a fraqueza do preimage compartilhado é, aliás, a motivação declarada pelos próprios desenvolvedores para a transição aos PTLCs.立証済み:Lightningのプライバシーに関する実証研究と、残高探知のための文書化されたプロービング攻撃がこれらのベクトルを示している。しかも共有プリイメージの弱点は、開発者自身がPTLC移行の動機として明言しているものである。成立:关于Lightning隐私的实证研究和用于探测余额的已记录探测攻击证明了这些攻击向量;而共享原像这一弱点,正是开发者自己宣称转向PTLC的动机。مثبت: تثبت الدراسات التجريبية حول خصوصية Lightning وهجمات السبر الموثقة لاكتشاف الأرصدة هذه المسارات؛ كما أن ضعف الصورة الأولية المشتركة هو الدافع الذي أعلنه المطورون أنفسهم للانتقال إلى PTLC.
Das spieltheoretische „Betrug lohnt sich nicht" setzt Liveness voraus: Die Bestrafung alter Kanalzustände funktioniert nur, wenn das Opfer oder ein Watchtower innerhalb des Timelocks online ist – eine Annahme, die viele Mobilnutzer nicht erfüllen; Watchtowers erwähnt der Artikel nicht.The game-theoretic claim that fraud does not pay assumes liveness: punishing old channel states only works if the victim or a watchtower is online within the timelock — an assumption many mobile users do not meet; the article never mentions watchtowers.La tesis de teoría de juegos de que el fraude no compensa presupone liveness: castigar estados antiguos del canal solo funciona si la víctima o un watchtower está en línea dentro del timelock, un supuesto que muchos usuarios móviles no cumplen; el artículo ni siquiera menciona los watchtowers.A tese de teoria dos jogos de que a fraude não compensa pressupõe liveness: punir estados antigos do canal só funciona se a vítima ou um watchtower estiver online dentro do timelock — um pressuposto que muitos usuários móveis não cumprem; o artigo nem menciona watchtowers.「不正は割に合わない」というゲーム理論的主張は稼働状態(Liveness)を前提とする。古いチャネル状態への処罰は、被害者かWatchtowerがタイムロック内にオンラインである場合にのみ機能するが、多くのモバイルユーザーはこの前提を満たさない。記事はWatchtowerに一切触れていない。「作弊不划算」这一博弈论主张以在线状态为前提:惩罚旧通道状态只有在受害者或Watchtower于时间锁窗口内在线时才有效——许多移动用户并不满足这一假设;文章对Watchtower只字未提。الطرح القائم على نظرية الألعاب بأن الغش لا يجدي يفترض الجاهزية المستمرة: فمعاقبة حالات القناة القديمة لا تعمل إلا إذا كان الضحية أو خدمة Watchtower متصلا خلال نافذة القفل الزمني — وهو افتراض لا يحققه كثير من مستخدمي الهواتف؛ والمقال لا يذكر خدمات Watchtower إطلاقا.
Belegt: Die Strafmöglichkeit ist protokollbedingt an Überwachung innerhalb des Timelocks gebunden – genau deshalb existiert das gesamte Watchtower-Ökosystem. Für sporadisch verbundene Nutzer schwächt sich das im Artikel gefeierte Gleichgewicht real ab.Substantiated: by protocol design, punishment is tied to monitoring within the timelock — which is exactly why the entire watchtower ecosystem exists. For sporadically connected users, the equilibrium the article celebrates genuinely weakens.Confirmado: por diseño del protocolo, el castigo está ligado a la vigilancia dentro del timelock; exactamente por eso existe todo el ecosistema de watchtowers. Para usuarios conectados de forma esporádica, el equilibrio que celebra el artículo se debilita realmente.Confirmado: por design do protocolo, a punição está ligada ao monitoramento dentro do timelock — exatamente por isso existe todo o ecossistema de watchtowers. Para usuários conectados esporadicamente, o equilíbrio que o artigo celebra enfraquece de fato.立証済み:プロトコル設計上、処罰はタイムロック内の監視に依存している。Watchtowerというエコシステム全体が存在するのはまさにそのためである。散発的にしか接続しないユーザーにとって、記事が称える均衡は現実に弱まる。成立:按协议设计,惩罚依赖于时间锁窗口内的监控——整个Watchtower生态的存在正是为此。对只是偶尔联网的用户来说,文章称颂的均衡确实被削弱。مثبت: بحكم تصميم البروتوكول، ترتبط العقوبة بالمراقبة خلال نافذة القفل الزمني — ولهذا السبب بالضبط توجد منظومة Watchtower بأكملها. وبالنسبة للمستخدمين المتصلين بشكل متقطع، يضعف فعليا التوازن الذي يحتفي به المقال.
„Minimale Kosten" gilt nur bedingt: On-Chain-Gebühren für Öffnung und Schließung, unökonomische Force-Closes in Gebührenspitzen und Dust-HTLCs können kleine Kanäle wirtschaftlich entwerten – Angriffe wie Flood & Loot zielen genau auf diese Lücke.Minimal cost holds only conditionally: on-chain fees for opening and closing, uneconomical force-closes during fee spikes, and dust HTLCs can economically hollow out small channels — attacks like Flood & Loot target exactly this gap.El coste mínimo solo se cumple condicionalmente: las comisiones on-chain de apertura y cierre, los force-close antieconómicos durante picos de comisiones y los dust HTLC pueden vaciar económicamente los canales pequeños; ataques como Flood & Loot apuntan exactamente a esa brecha.O custo mínimo vale apenas condicionalmente: taxas on-chain de abertura e fechamento, force-closes antieconômicos em picos de taxas e dust HTLCs podem esvaziar economicamente canais pequenos — ataques como Flood & Loot miram exatamente essa brecha.「最小限のコスト」は条件付きでしか成り立たない。チャネル開閉のオンチェーン手数料、手数料急騰時の不経済な強制クローズ、ダストHTLCは小さなチャネルを経済的に空洞化させうる。Flood & Lootのような攻撃はまさにこの隙を突く。「成本极低」只在有条件下成立:开关通道的链上费用、费用飙升期不划算的强制关闭以及粉尘HTLC,都可能让小通道在经济上失去意义——Flood & Loot这类攻击瞄准的正是这个缺口。لا يصح ادعاء الكلفة الدنيا إلا شرطيا: فرسوم فتح القنوات وإغلاقها على السلسلة، والإغلاقات القسرية غير الاقتصادية أثناء ذروات الرسوم، وعقود HTLC الغبارية قد تفرغ القنوات الصغيرة اقتصاديا — وهجمات مثل Flood & Loot تستهدف هذه الثغرة تحديدا.
Belegt: Forschung (Harris/Zohar 2020) und die Gebührenspitzen 2023–2024 zeigen, dass die Durchsetzung der Sicherheitsgarantien bei kleinen Kanälen teurer sein kann als das Kanalguthaben. Die Kostenaussage des Artikels gilt amortisiert – für hinreichend große, langlebige Kanäle.Substantiated: research (Harris/Zohar 2020) and the 2023-2024 fee spikes show that enforcing the security guarantees on small channels can cost more than the channel balance itself. The article's cost claim holds in amortized terms — for sufficiently large, long-lived channels.Confirmado: la investigación (Harris/Zohar 2020) y los picos de comisiones de 2023-2024 muestran que hacer valer las garantías de seguridad en canales pequeños puede costar más que el propio saldo del canal. La afirmación de costes del artículo se cumple de forma amortizada, para canales suficientemente grandes y longevos.Confirmado: a pesquisa (Harris/Zohar 2020) e os picos de taxas de 2023-2024 mostram que fazer valer as garantias de segurança em canais pequenos pode custar mais do que o próprio saldo do canal. A afirmação de custos do artigo vale de forma amortizada — para canais suficientemente grandes e duradouros.立証済み:研究(Harris/Zohar 2020)と2023〜2024年の手数料急騰は、小さなチャネルでは安全性保証の執行コストがチャネル残高を上回りうることを示している。記事のコスト主張は、十分に大きく長寿命なチャネルについて償却ベースでのみ成り立つ。成立:研究(Harris/Zohar 2020)与2023-2024年的费用飙升表明,在小通道上执行安全保障的成本可能超过通道余额本身。文章的成本论断只在摊销意义上、对足够大且长期存在的通道成立。مثبت: تظهر الأبحاث (Harris/Zohar 2020) وذروات الرسوم في 2023-2024 أن إنفاذ ضمانات الأمان على القنوات الصغيرة قد يكلف أكثر من رصيد القناة نفسه. وادعاء الكلفة في المقال يصح بالمعنى الإطفائي — للقنوات الكبيرة طويلة العمر بما يكفي.
QuellenSourcesFuentesFontes出典来源المصادر
- Bitcoin Lightning Network Whitepaper – Poon & Dryja (lightning.network)
- BOLT Specifications (Basis of Lightning Technology) – GitHub (github.com)
- mempool.space Lightning Explorer (mempool.space)
- Bitcoin Wiki: Payment Channels (en.bitcoin.it)
- BIP 68 – Relative lock-time using consensus-enforced sequence numbers (CSV) (github.com)
- Blocktrainer: Lightning Network erklärt (blocktrainer.de)
Social-Media-Posts (vom Team erstellt)Social media posts (drafted by the team)Publicaciones en redes sociales (redactadas por el equipo)Publicações em redes sociais (redigidas pela equipe)ソーシャルメディア投稿(チームが作成)社交媒体帖子(由团队起草)منشورات وسائل التواصل الاجتماعي (من إعداد الفريق)
Wie funktionieren Lightning-Kanäle wirklich? Von der Funding Transaction bis zum Onion Routing – technisch fundiert erklärt. #Bitcoin #LightningNetworkHow do Lightning channels actually work? From funding transactions to onion routing – explained with technical depth. #Bitcoin #LightningNetwork¿Cómo funcionan realmente los canales de Lightning? Desde la transacción de financiamiento hasta el enrutamiento cebolla - explicado técnicamente. #Bitcoin #RedDeLightningComo funcionam realmente os canais de lightning? Da transação de financiamento até o roteamento de cebola - explicado tecnicamente. #Bitcoin #RedeLightningLightningカーニュールはどのように機能するか?ファンディングトランザクションからオニオンルーティングまで、技術的に詳しく説明。#ビットコイン #ライトニングネットワーク什么是闪电网络?从资金事务到洋葱路由 - 技术上详细解释。#比特币 #闪电网络كيف يعمل قنوات الضوء الفعلية؟ من عملية التمويل حتى التوجيه المعكوس - تفسير تقني. #بيتكوين #شبكة_الضوء
Das Lightning Network macht Bitcoin-Zahlungen sofort und günstig – aber wie genau? Dieser Artikel erklärt, wie Zahlungskanäle geöffnet und geschlossen werden, warum HTLCs Atomarität garantieren und wieso Betrug im Netzwerk spieltheoretisch keinen Sinn ergibt. Onion Routing sorgt dabei für Privatsphäre by Design. Pflichtlektüre für alle, die Lightning wirklich verstehen wollen.The Lightning Network makes Bitcoin payments instant and cheap – but how exactly? This article explains how payment channels are opened and closed, why HTLCs guarantee atomicity, and why cheating is game-theoretically irrational. Onion routing provides privacy by design. Essential reading for anyone who wants to truly understand Lightning.La red de iluminación Lightning hace pagos de Bitcoin inmediatos y económicos, pero ¿cómo exactamente? Este artículo explica cómo se abren y cierran canales de pago, por qué los HTLC garantizan atomicidad y por qué el fraude en la red no tiene sentido desde el punto de vista de la teoría de juegos. La enrutación a cebolla proporciona privacidad por diseño. Lectura obligada para todos aquellos que quieren entender realmente Lightning.A rede Lightning Network torna os pagamentos de Bitcoin instantâneos e baratos - mas como exatamente? Este artigo explica como os canais de pagamento são abertos e fechados, por que as HTLCs garantem atomicidade e por que o fraude na rede não faz sentido do ponto de vista da teoria dos jogos. O onion routing é responsável pela privacidade por design. Leitura obrigatória para todos aqueles que querem realmente entender Lightning.ライトニング・ネットワークは、ビットコインの支払いを即時で安価にするが、それはどのようにして実現しているのか?この記事では、支払いチャネルを開閉する方法、HTLC(Hashed Time-Locked Contract)が原子性を保証する理由、およびネットワーク内での詐欺がゲーム理論的に意味がない理由について説明します。オニオン・ルーティングはプライバシーのデザインを提供しています。この記事は、ライトニングを本当に理解したいすべての人々の必読書です。Lightning 网络使 Bitcoin 交易立即且廉价 - 但具体如何? 这篇文章解释了如何打开和关闭支付渠道、为什么 HTLCs 原子性保证以及为什么欺诈在网络中从理论上没有意义。Onion 路由提供了隐私的设计。 对所有想真正理解 Lightning 的人来说是必读材料。تُجعل payments بالBitcoin lightning network فوريةً وسعرًا منخفضًا - لكن كيف بالضبط؟ هذا المقال يشرح كيف يتم فتح وتغلق قنوات الدفع، ومتى تأمُل HTLCs التأكيدية، ولماذا لا يجعل الخداع في الشبكة منطقية من النظرية اللعب. Routing التنين هو المسؤول عن الخصوصية بواسطة التصميم. قراءة إلزامية للجميع الذين يرغبون في فهم lightning حقيقتها.