Ist Channel Jamming eine Bedrohung für das Lightning Network von Bitcoin?

(Besonderer Dank gilt Antoine Riard und Gleb Naumenko, deren neuere Forschungen ist die Grundlage dieses Artikels.)

Channel Jamming ist eines der herausragenden Probleme des Lightning-Netzwerks in Bezug auf Dinge, die den Erfolg der darüber geleiteten Zahlungen stören könnten. Es ist ein weithin bekanntes Problem unter Entwicklern, das bereits verstanden wurde, bevor das Netzwerk selbst tatsächlich im Mainnet live ging und mit der Verarbeitung auch nur eines einzigen Satoshi begann.

Bisher hatte das Problem keine wirklich negativen Auswirkungen auf das Netzwerk, aber wenn man diese Tatsache berücksichtigt, ist es wichtig zu bedenken, dass das Netzwerk im Großen und Ganzen immer noch relativ klein ist. Handelsprozessoren haben damit begonnen, es zu unterstützen, ebenso wie einige Börsen und viele native Lightning/Bitcoin-Dienste und -Unternehmen, aber in Wirklichkeit ist das nicht viel. Das Netzwerk ist immer noch eine sehr kleine Sache, die hauptsächlich von Bitcoinern genutzt wird, und das ist überhaupt kein sehr großer Teil der Welt.

Darüber hinaus ist die Anzahl der Bitcoiner, die ihre Bitcoin regelmäßig in Handelsumgebungen ausgeben und verwenden, eine noch kleinere Teilmenge dieser bereits kleinen Gruppe. Nur weil mögliche Angriffe jetzt nicht stattfinden, sollten die Leute nicht davon ausgehen, dass sie auch weiterhin nicht stattfinden werden, wenn das Netzwerk zu einem größeren Maßstab wächst. Je größer es wird, desto wettbewerbsfähiger und gegnerischer wird es.

Was ist Kanalstörung?

Das grundlegende Konzept des Kanalstaus besteht darin, Zahlungen durch einen Lightning-Kanal zu leiten, den Sie von sich selbst blockieren möchten, und sie dann nicht abzuschließen, indem Sie das Preimage an den Zahlungs-Hash im freigeben Hashed Timelock Contracts (HTLCs). Das/die Opfer können die HTLCs erst nach Ablauf der Frist für die Rückerstattung aus ihrem Kanal entfernen, da sie keine Möglichkeit hätten, ihren Anspruch auf Geld geltend zu machen, das ihnen geschuldet wird, wenn das Urbild nach der Entfernung veröffentlicht würde. Wenn Sie auf diese Weise einen Kanal vollständig blockieren, kann dieser Kanal keine Zahlungen weiterleiten, bis die Zeitsperre für alle böswilligen Zahlungen abgelaufen ist.

Hier gibt es zwei unterschiedliche Strategien, um den Angriff durchzuführen. Sie können entweder versuchen, die in einem Kanal verfügbare routbare Menge zu blockieren, oder Sie können versuchen, alle einzelnen HTLC-Slots in einem Kanal zu blockieren. Ein Lightning-Kanal kann nur 483 ausstehende HTLCs in jede Richtung haben, die er weiterleiten kann – das liegt daran, dass es eine maximale Größenbeschränkung für die Größe einer Bitcoin-Transaktion gibt. Wenn Sie mehr als 483 HTLCs pro Richtung im Kanal hinzufügen, wäre die Transaktion zum Schließen des Kanals bei Bedarf zu groß und nicht gültig, um sie an das Netzwerk zu übermitteln. Dies würde alles im Kanal in der Kette nicht durchsetzbar machen.

Ein Angreifer kann also entweder versuchen, die gesamte Liquidität in einem Kanal zu sperren, oder versuchen, alle HTLC-Slots in einem Kanal zu sperren. Beide Strategien würden den Kanal unbrauchbar machen, aber Slot-Jamming ist im Allgemeinen billiger als Betrags-Jamming. Der Angreifer muss Münzen im Netzwerk haben, um diesen Angriff durchzuführen, daher wird das Routing des minimal zulässigen Werts für eine HTCL mit 483 Kapazität kostengünstiger sein, als zu versuchen, die gesamte im Kanal verfügbare Liquidität zu sperren.

Warum sollte jemand einen Beleuchtungskanal blockieren wollen?

Es gibt viele Gründe, diesen Angriff durchzuführen. Erstens könnte eine böswillige Entität, die Bitcoin selbst angreifen möchte, alle wichtigen Kanäle im „Kern“ des Netzwerks blockieren, um den größten Teil des Netzwerks für das Routing von Zahlungen unbrauchbar zu machen, mit Ausnahme von Knoten, die sehr eng miteinander verbunden sind . Dies würde viel mehr Münzen erfordern, um in dieser Größenordnung zu funktionieren, sollte aber nicht als Möglichkeit außer Acht gelassen werden, je mehr Bitcoin wächst und zu einer Alternative zu staatlich sanktionierten Geld- und Zahlungssystemen wird.

Zweitens könnte ein Routing-Knoten oder Händler versuchen, den Angriff auf einen Konkurrenten durchzuführen, um ihm im Gegensatz zur Konkurrenz Gebühren aufzuerlegen. Ein Händler, der ähnliche Produkte verkauft, könnte die Kanäle eines Konkurrenten blockieren, um Kunden daran zu hindern, dort einzukaufen, in der Hoffnung, sie zu motivieren, stattdessen in ihrem Geschäft einzukaufen. Ein Routing-Knoten, der eine ähnliche Kanalkonnektivität wie ein anderer Knoten hat, könnte die Kanäle des konkurrierenden Routing-Knotens blockieren, um sie für das Routing von Zahlungen unbrauchbar zu machen. Im Laufe der Zeit würde dies den Ruf dieses Knotens in Bezug auf die Routing-Zuverlässigkeit zerstören und es aufgrund ähnlicher Konnektivität immer wahrscheinlicher machen, dass die Brieftaschen der Benutzer den Knoten des Angreifers wählen, um Zahlungen über das Netzwerk zu leiten.

Diese Angriffe können für den Angreifer sogar noch kapitaleffizienter sein, wenn sie mehrmals im Kreis durch einen einzigen Kanal geleitet werden. Wenn sie dem Opfer im Netzwerk nahe genug sind, können sie eine Zahlungsroute aufbauen, die sich um den Kanal des Opfers dreht und weitergeht. Es gibt Grenzen, wie lang eine Zahlungsroute sein kann, daher kann dies nicht unendlich geschehen, aber die Ausführung einer sich wiederholenden Zahlungsroute wie dieser kann die Menge an Coins, die der Angreifer benötigt, um den/die Kanal(e) eines Opfers vollständig zu blockieren, drastisch verringern.

Minderung von Channel-Jamming-Angriffen

Einige grundlegende, partielle Minderungen könnten angewendet werden, um die Kosten für Angreifer zu erhöhen und den Schaden für die Opfer zu mindern. Das erste wäre ein mehrstufiges Verfahren zur Handhabung von HTLCs.

Gegenwärtig fügt jeder HTLC individuell eine neue Ausgabe in der Commitment-Transaktion für den aktuellen Kanalzustand hinzu. Ein zweistufiger Prozess könnte eine einzelne zusätzliche Ausgabe in der Commitment-Transaktion erzeugen und dann eine zweite Transaktion nach dieser haben, zu der der eigentliche HTLC hinzugefügt wird. Dies würde maximal 483 multipliziert mit 483 HTLC-Slots pro Kanal (oder 233,289 Slots) ermöglichen. Dies behebt jedoch nicht wirklich etwas von selbst und würde eine Verlängerung der Zeitsperren erfordern, da Sie eine zusätzliche Transaktion hinzufügen, um Dinge in der Kette durchzusetzen, und dem Angreifer tatsächlich mehr helfen könnte als dem Opfer, wenn er diese neue Transaktionsstruktur und die Opfer nicht. Es wird jedoch in Kombination mit einer anderen Technik, die gleich erklärt wird, hilfreich sein.

Die zweite wäre eine reaktive Strategie, bei der ein Knoten, der Opfer einer Störung geworden ist, einfach einen neuen Kanal zu demselben Peer wie dem, der gestört wird, öffnen kann. Dies würde jedoch zusätzliches Kapital erfordern, um die Opportunitätskosten für die Blockierung des anderen Kanals und den Verlust von Gebühreneinnahmen nicht zu beheben, und der neue Kanal könnte anschließend ebenfalls blockiert werden, wenn der Angreifer das verfügbare Kapital dafür hat .

Die dritte Technik wäre das Bucket von HTLC-Slots. Derzeit gibt es 483 Slots, und dies ist ein einziges Slot-Limit, das universell auf alle Zahlungen angewendet wird, unabhängig vom Wert der Zahlung. Knoten könnten separate Buckets mit kleineren Slot-Limits erstellen und sie auf Zahlungen mit unterschiedlichen Werten anwenden, dh Zahlungen von 100,000 Sats oder weniger könnten nur Zugang zu 150 Slots haben. Daher können Routing-Zahlungen mit kleinerem Wert nicht alle verfügbaren HTLC-Slots verbrauchen.

Zahlungen von 100,000 Sats an 1 Million Sats könnten Zugang zu 300 Slots haben, und 1 Million Sats an 10 Millionen Sats könnten Zugang zu den vollen 483 Slots haben. Dies würde die Kapitalkosten eines Angreifers für Slot-Jam erheblich erhöhen, da er nicht mehr in der Lage wäre, alle 483 Slots mit der kleinstmöglichen Wertzahlung zu verbrauchen. Da außerdem HTLC-Ausgaben unterhalb der Staubschwelle (derzeit 546 Sats) nicht einmal gesendet und in der Kette durchgesetzt werden können, könnte alles unterhalb dieser Grenze als „0-Eimer“ behandelt werden, da sowieso keine HTLC-Ausgabe erzeugt wird. Knoten könnten diese Transaktionen einfach auf der Grundlage der verwendeten CPU-Ressourcen oder anderer Metriken begrenzen, um zu verhindern, dass sie zu Denial-of-Service-Risiken werden, je nachdem, wie viel sie sich leisten können zu verlieren, wenn sie nicht ehrlich abgerechnet werden.

Slot-Bucketing in Kombination mit zweistufiger HTLC-Handhabung kann verwendet werden, um die Anwendung von HTLC-Limits zu optimieren, dh Zahlungen mit höherem Wert können die zweistufige Struktur verwenden, um mehr Slots für sie pro Kanal zu erstellen, da der höhere Zahlungswert die Kosten erhöht sie für einen Angreifer zu blockieren, wodurch der Missbrauch eines höheren Slot-Limits zum Ausführen von Jamming-Angreifern weniger wahrscheinlich wird.

In ihrer oben zitierten Forschung haben Riard und Naumenko gezeigt, dass mit der optimalen Kombination von Bucketing-Schlitzen und einer zweistufigen Schlitzerweiterung die Ursache der Schlitzstauung genauso teuer gemacht werden kann wie die Mengenstauung. Dies würde das Problem nicht umfassend lösen, aber es erhöht die minimalen Kosten für die Durchführung des Angriffs, wenn es von Knoten im gesamten Netzwerk umfassend implementiert wird.

Die beiden umfassenden Lösungen, die sie sich angesehen haben, sind eine Vorab-/Haltezeitgebühr zum Sperren von Liquidität und ein Reputationssystem, das blinde Chaumian-Token verwendet. Die TLDR des Gebührensystems besteht darin, dass eine Anleihe für eine Vorabgebühr für das Routing eines HTLC gezahlt wird, dessen Abwicklung voraussichtlich lange dauern wird, und je länger es ungeklärt bleibt, es würde eine Gebühr an jeden Routing-Knoten freigeben pro Zeitabschnitt, der ohne Abrechnung vergangen ist. Das Problem ist, dass die Durchsetzung dazu führen könnte, dass Kanäle geschlossen werden müssen, wenn die Gebühren nicht bei Bedarf gesendet werden, und dass legitime Anwendungsfälle, die lange Sperrzeiten erfordern, dazu führen, dass die gleiche höhere Gebühr gezahlt wird, die ein Angreifer, der versucht, Kanäle zu blockieren, zahlen würde.

Das Reputationsschema würde eine „Einsatzbindung“ beinhalten, die Zero-Knowledge-Beweise verwendet, um die Kontrolle über Bitcoin als Sybil-Verteidigung nachzuweisen, und dann die an Ihre Reputation gebundene Bindung verwendet, um geblendete chaumianische Token von Routing-Knoten zu erwerben, die bei HTLCs eingelöst und neu ausgegeben würden sich erfolgreich auf eine die Privatsphäre wahrende Weise niederzulassen. Nodes würden Token einmal pro Identität ausgeben, und wenn ein HTLC nicht rechtzeitig abgerechnet oder zurückerstattet wurde, könnten Nodes die Neuausgabe des Tokens verweigern, wodurch ein Benutzer daran gehindert wird, durch seinen Node zu leiten, es sei denn, er investiert Zeit und Geld, um einen neuen zu erstellen Stake Bond mit verschiedenen Coins, die in einem frischen Token ausgegeben werden.

Für diejenigen, die mehr über diese beiden Lösungen lesen möchten, finden Sie weitere Informationen in den Abschnitten fünf und sechs in Riards und Naumenkos Forschung.

Es ist auch erwähnenswert, dass Routing-Knoten Treuhandsysteme von Drittanbietern oder vertrauensbasierte Kreditlinien übernehmen würden, wie ich darüber geschrieben habe hier, würden all diese Probleme im Zusammenhang mit Kanalstörungen sie nicht mehr betreffen. Dies wäre eine große Änderung des Vertrauensmodells für Routing-Knoten, aber es hätte keine Auswirkungen auf Personen, die echte Lightning-Kanäle zum Senden und Empfangen von Sats verwenden, die Sicherheit ihrer Gelder oder ihre Fähigkeit, dies in der Kette durchzusetzen.

Die Leute möchten es vielleicht nicht hören, aber am Ende des Tages, wenn die oben genannten Lösungen zur Minderung von Kanalstörungen für tatsächliche Kanäle nicht ausreichen, sind diese Systeme von Drittanbietern immer eine mögliche Option.

Dies ist ein Gastbeitrag von Shinobi. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.