Digitales Offline-Geld?

Immer wieder taucht die Frage nach dem Einsatz von digitalem Geld bei Netzausfall auf. Hier eine Übersicht über die Möglichkeiten und ihre Vor- und Nachteile.

Mehr Informationen zu digitalem Geld, digitalen Werten und Blockchain gibt es hier. This article is also available in English 🇬🇧: «Offline Digital Cash?»

Manipulationssichere Hardware

Die ersten Bancomaten verfügten über Offline-Funktionen, entweder als Standard oder als Fallback bei Netzausfall. Dabei wurden sowohl der Automat selbst als auch der Magnetstreifen der Bankkarte als manipulationssicher angesehen, da Magnetstreifenleser damals nicht breit zugänglich waren.

Seit vielen Jahren gelten Magnetstreifen nicht mehr als manipulationssicher. Als Ersatz dienen inzwischen Chipkarten, die deutlich schwerer (aber nicht unmöglich) zu manipulieren sind.

Viele moderne Prozessoren ermöglichen auch Software in einer speziellen Umgebung laufen zu lassen, um Manipulationen an dieser Software und ihren Daten zu erschweren oder zu verunmöglichen. So kann manipulationssichere Hardware angenähert werden.

Wenn bei einer Finanztransaktion auf beiden Seiten nur manipulationssichere Systeme zum Einsatz kommen, kann diese Transaktion auch offline ausgeführt werden. Dies erfordert jedoch sehr hohes Vertrauen in den Lieferanten der entsprechenden Systeme, da diese systembedingt nicht unabhängig inspiziert werden können, insbesondere nicht vom Kunden.

Transparente Lösungen

Sobald das System aber unabhängig inspizierbar sein soll (z.B. FOSS), wechseln wir das Spielfeld und haben nun ein Verteiltes System. Insbesondere benötigen wir die Möglichkeit, das mehrfache Ausgeben eines digitalen Wertgegenstandes zu verhindern oder zumindest zu erkennen. Zum Schutz vor diesem „Double Spending“ muss jemand Buch führen über die Ausgaben. Dies bedeutet auch, dass nicht mehr alle Beteiligten am selben Ort sind.

Zwei Stufen

Zu beachten ist, dass wir auf zwei Ebenen Verteilte Systeme haben:

1. Das Transaktions-System zwischen den beiden Zahlungsteilnehmern, dem (buchführenden) Zeugen und dem sie verbindenden Netzwerk.
2. Das Datenbank-System des Zeugen, in dem die Transaktionen gespeichert sind; ebenfalls inklusive einem Netzwerk zur Verbindung.

Die Struktur, Skalierung, und Ausfallstoleranz des Datenbanksystems ist dem „Zeugen“ (klassischerweise einem Payment Services Provider) überlassen. Ohne Beschränkung der Allgemeinheit können wir es als zentralisiertes System, d.h. einen einzelnen Datenbankmaster, ansehen. (Typischerweise dürfte das System als Rechnerverbund mit primary/secondary– bzw. active/active-Replikation sein.)

(Es spricht übrigens nichts prinzipiell dagegen, diese Datenbank auch als Blockchain zu implementieren. Es gilt aber die Komplexität, fehlende Vorhersagbarkeit bzw. Tuningmöglichkeiten von Systemeigenschaften, schlechte Managebarkeit, schwer abschätzbares Verhalten im Fehlerfalle (Netzausfall/Partitionierung) und Kosten abzuwägen gegen eine von klar definierten Playern umgesetzte Lösung mit Transparenz, Accountability und Übernahme der Verantwortung.)

Uns interessiert hauptsächlich das Transaktionssystem, welches wir nun genauer beleuchten:

Basislösung („zentral“)

In diesem System kontaktieren beide Zahlungsteilnehmer den Zeugen. Sofern dieser erreichbar und funktionsfähig ist, wird die Transaktion durchgeführt.

In diesem Falle haben wir maximale Konsistenz („Consistency“), im Falle eines Netzausfalls („Partition“) ist die Verfügbarkeit („Availability“) gleich Null.

Quorum

Das Datenbanksystem wird oftmals mittels eines Quorums und geografischer Verteilung umgesetzt. Auch wenn ein einzelnes Rechenzentrum nicht mehr erreichbar wäre, könnten weiterhin Transaktionen durchgeführt werden.

Auch wenn einzelne Netzwerkverbindungen ausfallen, kann das System weiterhin konsistent verfügbar bleiben.

(Dieser Fall hätte auch als interne Struktur des Datenbanksystems abgebildet werden können; sie ermöglicht aber einen erläuternden Zwischenschritt zum nächsten Punkt.)

Regionale Ausfallsicherheit

Falls das digitale Geld, wie auch Bargeld, hauptsächlich regional eingesetzt wird, kann die alleinige (oder zumindest Haupt-)Verantwortung für Geldstücke regional zugeordnet werden. Damit liesse sich das System weiter betreiben, auch wenn die Netzwerkverbindungen global gestört sind; so lange sie lokal noch funktionieren.

In vielen Fällen (lokal erworbenes Geld wird auch lokal wieder ausgegeben) ergibt sich damit eine höhere Verfügbarkeit im Partitionsfall, bei Beibehaltung der Konsistenz.

Offline: Konsistenz

Falls das Netzwerk gar nicht verfügbar ist, können Konsistenz und Verfügbarkeit nicht mehr gleichzeitig erreicht werden. Falls Konsistenz unabdingbar ist, wird die Verfügbarkeit wegfallen, d.h.:

Zahlungen sind nicht mehr möglich. (Identisch zu „zentral“ bei Ausfall.)

Offline: Verfügbarkeit („opportunistisch“)

Falls Verfügbarkeit hoch bewertet wird, erhalten wir ein opportunistisches Zahlungssystem: Der Händler muss dem Kunden (während dem Ausfall) glauben, dass er das Geld noch nicht ausgegeben hat. Bei bestehendem Vertrauensverhältnis und kleinem Betrag kann das Ausfallrisiko klein gehalten werden. Sobald das Netzwerk wieder für alle verfügbar ist, erhält der Händler die Gewissheit, in die eine oder andere Richtung.

Zahlungen sind möglich, basieren aber auf Vertrauen.

Bei eCash (und dem davon abgeleiteten GNU Taler) wird die Anonymität des Kunden automatisch aufgehoben, falls eine Münze mehrfach ausgegeben ist. Damit kann der (zechprellende o.ä.) Kunde identifiziert und belangt werden. Bei Bedarf könnte dieser Prozess auch automatisiert werden; bisher ist die Offline-Operation aber nur als Notnagel vorgesehen.

Schlussfolgerung

Offline-Finanztransaktionen scheinen prinzipbedingt nur in Systemem möglich, welche sich dem Nutzer als Black Box zeigen und keinen Einblick in seine Funktionsweise zulassen. Sobald diese Einblicke gewünscht sind, sind Offline-Transaktionen maximal noch opportunistisch möglich.