HOPR Basics: Cover Traffic Nodes

Das ist die zehnte Folge in unserer Serie über die Grundlagen von HOPR. Links zu früheren Folgen findest du am Ende des Artikels.

Das ist die zehnte Folge in unserer Serie über die Grundlagen von HOPR. Links zu früheren Folgen findest du am Ende des Artikels.

In der letzten Folge wurde das Konzept des Cover-Traffics erklärt: willkürliche Daten, die durch das Netzwerk geschickt werden, um sicherzustellen, dass die Daten immer getarnt sind, um die Aktivität der Nutzer zu verbergen, selbst zu Zeiten, in denen der echte Traffic, also Pakete mit Daten, begrenzt ist.

Eine der Innovationen von HOPR ist die direkte Verknüpfung von Cover Traffic mit dem Staking: Je mehr HOPR-Token du hast, desto mehr Cover Traffic erhältst du und desto mehr HOPR-Token verdienst du für die Weiterleitung.

Dies ist aus mehreren Gründen nützlich: Der zusätzliche konsistente wirtschaftliche Motivation ermutigt langlebige und zuverlässige Nodes. Das Einbinden von Staking-Auszahlungen — ein erwartetes Feature vieler Kryptowährungen — in den Mechanismus des Cover-Traffics hilft, einige extrem komplexe Probleme im Zusammenhang mit dem Wissen, wie viel Cover Traffic bereitgestellt werden muss und wer dafür bezahlt, zu umgehen.

In einer idealen Welt

In einem dezentralisierten Netzwerk wie HOPR würden im Idealfall einzelne Nodes dynamisch genau die richtige Menge an Cover Traffic zur Deckung der tatsächlichen Nutzer im Netzwerk senden. Wenn zu viel gesendet wird, wird wertvolle Bandbreite verbraucht, während bei zu wenig die Gefahr besteht, dass die Metadaten der Nutzer preisgegeben werden. Wenn die Zahl der Nutzer steigt, sinkt der Bedarf an Cover-Traffic und umgekehrt.

Leider wirft dies mehrere Probleme auf:

Erstens: Wer zahlt dafür? Cover Traffic ist, wie wir bereits gelernt haben, willkürlicher Datenverkehr, der im Idealfall nicht zu existieren braucht. Wenn einzelne Nodes für die Bereitstellung von Cover Traffic verantwortlich sind, müssten sie die Kosten selbst tragen. Dies steht im Widerspruch zu dem in früheren Folgen erörterten Ethos der Motivationsgestaltung, wonach das Netzwerkverhalten, das wir fördern wollen, direkt incentiviert werden muss.

Zweitens: Wie entscheiden die Knoten, wie viel Cover Traffic sie bereitstellen müssen? Dies ist ein etwas komplizierter Punkt, für den es sich lohnt, einen kurzen Umweg zu gehen.

Netzwerk-Nebel

Es gibt eine merkwürdige Eigenschaft dezentraler Netzwerke, die fast jede Frage des Protokollentwurfs verkompliziert: Die Nodes haben nie den vollen Überblick. Die Nodes wissen über ihre Peers Bescheid, und sie kennen die Informationen, die ihre Peers teilen, aber all diese Informationen werden immer unzuverlässiger, je mehr Zeit vergeht und je weiter man sich vom ursprünglichen Node entfernt.

Diese Unsicherheit wirkt sich auf alles aus, von der Routenplanung, welche ein Datenpaket einschlägt, über die Abwehr von Angriffen, bis hin zu grundlegenden Konzepten wie dem Beitritt zum Netzwerk. Da die Nodes bestenfalls ein vernebeltes Bild des Netzwerkes haben, ist es für einzelne Nodes demnach unmöglich, zu beurteilen, wie viel Cover Traffic benötigt wird. Wenn die Nodes versuchen, den Traffic, den sie direkt sehen, als Barometer zu verwenden, kommt es zu einer unglücklichen Rückkopplungsschleife, bei der der von einer Nodes bereitgestellte Cover Traffic eine Cover-Traffic Reaktion in einer anderen Node auslöst.

Anders ausgedrückt: Da Cover Traffic von vornherein nicht von echtem Traffic zu unterscheiden ist, gibt es für die einzelnen Nodes keine Möglichkeit festzustellen, ob sie echten Traffic sehen, der zusätzlichen Schutz benötigt, oder Cover Traffic selbst.

Cover Traffic Nodes

In seiner derzeitigen Version umgeht HOPR beide Probleme, indem wir spezielle Cover Traffic Nodes für den Cover Traffic bereitstellen. Zu Beginn wird der HOPR Association diese Nodes selbst betreiben, aber mittelfristig wird jeder in der Lage sein, eine Cover-Traffic Node zu betreiben, sofern er oder sie die Anforderungen erfüllt. Durch die zunehmende Bündelung dieser Verantwortung stellen wir sicher, dass das System für Cover Traffic zuverlässig ist, und verhindern einen theoretischen (aber extrem unwahrscheinlichen) Angriff, bei dem Cover Traffic Node Runners zusammenarbeiten, um das Netzwerk zu de-anonymisieren. Ein solcher Angriff könnte so aussehen, dass sie Informationen über den gesamten Traffic sammeln und die zusätzlichen Informationen, die sie über den Cover Traffic wissen, weil sie eine eigene Cover-Traffic Node bereitstellen, herausfiltern.

Aber selbst mit dedizierten Cover Traffic Nodes, die einige der dem Cover Traffic innewohnenden Probleme lösen, gibt es immer noch eine Menge weiterer Entscheidungen zu treffen. Cover Traffic Nodes müssen wie jede andere Node Daten durch das Netzwerk senden, was bedeutet, dass sie eine Route wählen müssen. Dies könnte rein auf der Höhe ihres Staking Einsatzes geschehen, aber wenn die Route fehlschlägt, weil die Nodes offline sind, dann verbrennen wir im Grunde genommen Token für nichts. Wenn wir aber ein anderes Kriterium wählen, z. B. Zuverlässigkeit, dann verdienen die Nodes nicht auf der Grundlage ihres Staking Einsatzes. Das heikle Problem, das wir uns in der nächsten Folge anschauen ist, wie man die fairen Belohnungen mit der Zuverlässigkeit des Netzwerks in Einklang bringt.

Dies ist eine Übersetzung vom Originalartikel “HOPR Basics: Cover Traffic Nodes”. Mehr zu HOPR und dem HOPR Protokoll findet ihr auf hoprnet.org oder auf medium.com/hoprnet

Webseite: https://hoprnet.org/de
Twitter: https://twitter.com/hoprnet
Telegram: https://t.me/hoprnet
Discord: https://discord.gg/dEAWC4G
LinkedIn: https://www.linkedin.com/company/hoprnet
Forum: https://forum.hoprnet.org

HOPR Basics Folgen:

Folge 1: Was ist HOPR?
Folge 2: Was sind Metadaten?
Folge 3: Anonymes Weiterleiten
Folge 4: Mixnets
Folge 5: Incentivierungen
Folge 6: Proof of Relay
Folge 7: Tickets und Zahlungskanäle
Folge 8: Probabilistische Zahlungen
Folge 9: Cover Traffic
Folge 10: Cover Traffic Nodes
Folge 11: Cover Traffic ausgleichen