Wie ein Distributed Ledger hilft

Genau das ist die Idee hinter der sogenannten Distributed-Ledger-Technologie (DLT), also einem verteilten Transaktionsprotokoll. Da diese Peer-to-Peer-Datenbank so lange weiterexistiert, wie noch eine einzige Instanz aktiv ist, sie also keinem Einzelnen gehört, der die Kontrolle über den Lebenszyklus hat, spricht man manchmal auch von Shared Distributed Ledger, also einem gemeinsamen, verteilten Transaktionsprotokoll.

Bei der DLT wird eine logisch zentrale Datenbank aller angefallenen Transaktionen aufgebaut, die aber technologisch über alle Knoten in einem Peer-to-Peer-Netzwerk verteilt ist. Alle Knoten in diesem Netzwerk besitzen den gleichen Datenbestand, und jede neue Transaktion wird immer an alle Knoten verteilt. Das hört sich sehr trivial an, jedoch muss man in einem solchen dezentralen System immer davon ausgehen, dass einzelne Knoten (bewusst oder unbewusst) Fehler produzieren.

Man kann mathematisch zeigen, dass in einem dezentralen System eine Einigung über die Korrektheit von Transaktionen nur unter bestimmten Bedingungen erfolgen kann (wird oft als „Problem der byzantinischen Generäle“ bezeichnet). Die Aufgabe der DLT ist nun, sicherzustellen, dass fehlerhafte Transaktionen erkannt werden und nicht den Weg in das Transaktionsprotokoll finden.

Üblicherweise ist eine weitere Eigenschaft der DLT, dass das Transaktionsprotokoll unveränderlich ist, das heißt, einmal erfasste Transaktionen können nicht mehr gelöscht werden. Es muss, vergleichbar mit der ordentlichen Buchhaltung, immer eine dokumentierte „Gegenbuchung“ erfolgen, um eine Transaktion rückgängig zu machen.

Für unser Beispiel bedeutet das, dass jeder Verkehrsbetrieb eine Kopie aller Daten besitzt und neue Fahrten aber erst als gültig und abrechenbar akzeptiert werden, wenn es einen Konsens unter den Beteiligten gibt, dass diese auch gültig sind. Dieses Verfahren wird als Consensus bezeichnet.

Damit jetzt nur Verkehrsbetriebe auf die Datenbank zugreifen können und nicht etwa unbeteiligte Dritte, wird diese Datenbank wieder abgesichert. So wird zum Beispiel über übliche Methoden wie etwa Authentifizierung oder Verschlüsselung sichergestellt, dass nur berechtigte Parteien an dem Peer-to-Peer-Protokoll teilnehmen können. In einem solchen Fall spricht man häufig auch von einem „Enterprise Consortium Network“, das heißt einem Netzwerk, das ausdrücklich den Mitgliedern eines Konsortiums vorbehalten ist. Rund um das Thema DLT haben sich in den vergangenen Jahren und Monaten eine Menge solcher Konsortien gebildet, unter anderem das B3i-Konsortium verschiedener großer Versicherungen oder R3, in dem sich neben diversen Banken auch Unternehmen wie Toyota und Microsoft wiederfinden.

Wenn man also über DLT spricht, dann spricht man nicht über eine konkrete Implementierung einer dezentralen Datenbank, sondern eher von dem Konzept der Kombination aus Peer-to-Peer-Netzwerken, dem Consensus-Verfahren, der Unveränderlichkeit des Transaktionsprotokolls und der Tatsache, dass die Datenbank von keinem einzelnen Unternehmen kontrolliert oder betrieben wird, sondern gleichermaßen (und in der Regel gleichberechtigt) von allen Mitgliedern eines bestimmten Kreises.

Die Implementierung erfolgt dann üblicherweise nicht auf Anwendungsebene, zum Beispiel für die Speicherung eines Monatstickets, sondern eher auf einer Protokollebene zum Austausch beliebiger Transaktionen. So kann die Datenbank auch für beliebige zukünftige Anwendungsfälle genutzt werden. Dies ist sicherlich ein großer Unterschied zu heutigen vergleichbaren Umsetzungen, wo bei der Zusammenarbeit von zwei oder mehr Unternehmen zum Beispiel konkrete Webschnittstellen für die Abwicklung bestimmter Geschäftsvorfälle definiert werden.