HOPR Basics: Incentivierung
Das ist die fünfte Folge in unserer Serie über die Grundlagen von HOPR. Links zu früheren Folgen findest du am Ende des Artikels.
In den vorangegangenen Folgen haben wir uns das Problem der offengelegten Verbindungs-Metadaten genauer angeschaut. Ausserdem haben wir uns mit der Frage befasst, wie man ein Mixnet verwenden kann, ohne dass Sender und Empfänger in Zusammenhang gestellt werden können.
In der Theorie hört sich das grossartig an, denn es zeigt, dass unser Ziel der privaten Datenübertragung machbar ist. Jedoch müssen wir uns jetzt überlegen, wie wir diese Theorie in die Praxis umsetzt. Deswegen gehen wir in dieser Folge auf das Problem der Incentivierung ein. Also wie sichergestellt werden kann, dass die Nodes angemessen belohnt werden und gleichzeitig ein vollständiger Schutz der Metadaten gewährleistet ist.
Wer bezahlt und wie wird bezahlt?
Das Verschlüsseln, Mischen, neu kombinieren und Weiterleiten ist sehr rechenintensiv im Vergleich zum direkten und offenen Senden von Daten. Wir brauchen also eine Möglichkeit, diese Kosten zu decken, sonst kann das Netzwerk nicht wachsen und sich entwickeln.
Einige Leute schätzen ihre Online-Privatsphäre so sehr, dass sie bereit sind, diese Kosten ohne Gegenleistung zu tragen. Das Tor-Projekt ist ein Beispiel für dieses Modell, es zeigt aber auch seine Grenzen auf. Während das Interesse an Dezentralisierung und Online-Privatsphäre in den letzten fünf Jahren exponentiell gewachsen ist, ist die Anzahl der Tor Relays und Bridges praktisch konstant geblieben.
Sich auf die Selbstlosigkeit der Menschen zu verlassen, ist weder nachhaltig noch fair. Wenn wir ein Netzwerk zum Schutz der Privatsphäre aufbauen wollen, welches das gesamte Internet abdecken kann, dann müssen die Nodes für ihre Arbeit bezahlt werden. Aber wer soll das bezahlen? Die Antwort liegt auf der Hand: Diejenigen, die am meisten von dem Netzwerk profitieren, nämlich die Personen, die es zur privaten Datenübertragung nutzen.
Warum also nicht genau das tun? Es gibt eine Gruppe von Leuten, die für den privaten Datenversand bezahlen wollen (Nutzer), und eine andere Gruppe, die diesen Dienst anbietet (Node Runner). Wir müssten sie doch nur miteinander verbinden.
Ein neues Zentralisierungsproblem
Es gibt zwei Möglichkeiten, die wir versuchen könnten, um Nutzer und Node Runner zu verbinden:
- Ein Abonnement. Die Nutzer zahlen für die Nutzung des Dienstes, die Gelder werden in einem Topf gesammelt und dann an die Node Runner verteilt.
- Direkte Bezahlung. Die Nutzer bezahlen die Node Runners direkt, wenn sie Daten über das Mixnet senden.
Die erste Option ist konzeptionell einfach, führt aber zu einem grossen Problem. Wer verwaltet die Gelder? Die Einführung einer zentralen Instanz, die für die Verwaltung einer umfassenden Liste von Nutzern und Node Runner zuständig ist, würde all die Arbeit vernichten, die wir bisher geleistet haben, um ein dezentrales Mixnet aufzubauen. Selbst wenn man dieser Instanz bei der Verwaltung der Daten vertrauen könnte (was man nicht kann), wäre sie ein grosses Ziel für Hacker Angriffe und externen Druck, Nutzerdaten zu verkaufen oder anderweitig offenzulegen.
Wir müssen also einen Weg finden, wie die Nutzer die Node Runner jedes Mal bezahlen können, wenn sie das Netzwerk nutzen. Da wir keinem fremden Administrator oder Dienst vertrauen können, ist die eleganteste Lösung, das HOPR-Netzwerk selbst für die Verwaltung dieser Zahlungen zu nutzen. Im Grunde ist eine Transaktion nur eine andere Art von Daten, die wir senden.
Geld weiterleiten
Erinnern wir uns kurz daran, was wir in früheren Folgen über das HOPR-Mixnet gelernt haben. Stellen wir uns vor, Alejandro sendet Daten an Zoe: Für jedes Paket wählt Alejandro (oder genauer gesagt seine Node) eine Route, die über einen oder mehrere Relayers (Node Runner) durch das Mixnet hüpft. Bei jedem Zwischenstopp entfernt dieser Relayer eine Verschlüsselungsschicht und sendet den Rest an den nächsten Zwischenstopp weiter.
Da diese Node Runner bezahlt werden müssen, ist es am logischsten, die Zahlung direkt in das Datenpaket aufzunehmen. Wenn dann ein Relayer das Paket “auspackt”, kann er oder sie seinen Anteil an der Zahlung einfordern und den Rest in der Kette weiterleiten. Ein bisschen wie eine digitale Version von “Pass the Parcel”.
Alejandro zahlt, um Daten über die gesamte Kette zu senden. Bei jedem Sprung fordert der Node Runner seinen Anteil an der Belohnung ein und sendet dann den Rest an den nächsten Relayer.
Wenn wir den Prozess also so aufgleisen, müssen wir sicherstellen, dass wir keine Zahlungs-Metadaten in die Blockchain einbringen. Zahlungs-Metadaten könnten es einem Angreifer wiederum ermöglichen, Verbindungen zwischen den einzelnen Personen in der Kette herzustellen. Denn wenn jemand den Zahlungsweg verfolgen kann, könnte er herausfinden, dass Alejandro Daten an Zoe gesendet hat. HOPR verschleiert diese Zahlungs-Metadaten mithilfe von Tickets, die eine zufällige Gewinnsumme enthalten, ähnlich wie bei einem Lotterielos. Wie und warum das funktioniert, werden wir in einer späteren Folge genauer erklären.
Warum Ball spielen?
Im Moment gibt es ein wichtigeres Problem zu bedenken — eines, das ein wenig paradox erscheinen mag. Wenn die Nodes vollkommen anonym sind und die Datenübertragung nicht nachverfolgt werden kann, wie können wir dann sicher sein, dass die Node Runner tatsächlich die Arbeit leistet, für die sie bezahlt werden?
Schau dir nochmals das obige Beispiel an und stell dir vor, du bist Betty. Wenn das Mixnet also völlig anonym ist, warum solltest du dir dann die Mühe machen, die erhaltenen Daten weiterzuleiten und Chao, die nächste Node in der Kette, zu bezahlen? Warum solltest du nicht das Geld nehmen und weglaufen, im Vertrauen darauf, dass die Anonymität des Netzes bedeutet, dass dich niemand aufhalten kann? In diesem Fall würde sich die Macht des Metadatenschutzes von HOPR sogar negativ auswirken. Wenn wir uns also auf Altruismus verlassen müssten, um sicherzustellen, dass die Daten tatsächlich weitergeleitet werden, wären wir wieder am Anfang.
Wir brauchen also einen Weg, der versichert, dass die Bezahlung einer Node erst erfolgt, wenn dieser die Daten weitergeleitet hat. Und hier kommt einmal mehr HOPR ins Spiel, denn wir haben eine der wichtigsten Innovationen in Petto. Sie heisst Proof of Relay. Was das ist und wie es funktioniert, werden wir uns in der nächsten Folge ansehen.
Dies ist eine Übersetzung vom Originalartikel “HOPR Basics: Incentives”. 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
