Blockchain-Anwendungsfall: Supply Chains meets Blockchain
Gleich vorweg, die Nutzung von Blockchains zur Verfolgung und Optimierung von Warenströmen sehe ich allgemein als kritisch. Dies hat verschiedene Gründe, die ich im folgenden erläutern möchte.
Welche Art von Blockchain?
Wenn ich von einer Blockchain rede, dann meine ich eine kryptografisch gesicherte Verkettung von Datensätzen in dieser Art.
Für Blockchain mit anderen Architekturen gelten folgende Aussagen folglich nicht automatisch, z.B. Sidechain-Architekturen oder wenn jedes Konto eine eigene Blockchain hat (z.B. Nano).
Außerdem ist meine Meinung bezüglich Lieferkettenanwendbarkeit fließend und vom Einzelfall abhängig. Ich lass mich gern vom Gegenteil überzeugen. Ausnahmen bestätigen - wie immer - die Regel. Will heißen, es gibt durchaus Anwendungsfälle, bei denen ein Blockchain eine gute oder vielleicht sogar die beste Lösung ist. Schreibt es bitte als Kommentar, wenn ihr anderer Meinung seid bzw. von einer guten Lösung per Blockchain-Technologie wisst.
Die Idee bei der Lieferkettenverfolgung
Hauptziele einer Lieferkette per Blockchain sind:
Kosten- und Zeitersparnis
Revisionssicherheit bei Informationen, d.h. aufbewahrungssichere/aufbewahrungswürdige Daten fälschungssicher mit einem Zeitpunkt zu speichern und abrufbar bereithalten
Transparenz und Vertrauensaufbau können weitere Ziele sein.
Genaugenommen geht dieser Blockchain-Anwendungsfall auf die bereits beschriebene Notarfunktion zurück.
Wer ist der Notar in einer Lieferketten?
Notar von Daten ist der jeweils Nächste in der Lieferkette, der bei Wareneingang Daten verifiziert. Er übernimmt eine Ware in einer bestimmten Menge und Qualität in seinen Verantwortungsbereich und protokolliert dies in der Blockchain.
In Lieferketten gibt es also nicht nur einen Notar, sondern mehrere.
Nicht jede Information für Jeden
Nicht nur bei Lieferketten über Zollgrenzen hinweg, sondern auch bei Lieferketten mit vielen Zulieferern, Transporteuren und Verarbeitern gibt es zahlreiche Akteure, bei denen Daten anfallen und die auf Daten aus vorherigen Prozessen aufbauen.
Nehmen wir das Beispiel Zoll- bzw. Frachtpapiere. Muss jeder Lieferkettenakteur alle Details dieser Dokumente einsehen können oder brauchen nur bestimmte Akteure dieses Privileg?
Vermutlich sollen bestimmte Akteure nur die für sie relevanten Daten einsehen können. Mich als Endnutzer eines Produktes interessieren Zollformalitäten wahrscheinlich nur wenig. Was mich aber interessiert, sind möglicherweise ein Okay des Zolls und alle beteiligten Akteure sowie Qualitätsdaten (Temperatur, Feuchtigkeit, Stoßparameter etc.) oder Mengendaten (z.B. bei kosmetischen, pharmazeutischen Produkten). Die Qualitätsdaten sind wiederum für die Zollabwicklung eher uninteressant.
Obacht
Aus den Mengendaten könnten Mitbewerber die genaue Produktzusammensetzung und die eingesetzten Herstellungsverfahren besser bestimmen. Unter Umständen lassen sich in überschaubaren Märkten einzelne Lieferanten identifizieren. Mengendaten von Halbzeugen können Geschäftsgeheimnisse darstellen. Sie haben aus Unternehmenssicht ein Schutzbedürfnis bzgl. einer Veröffentlichung. (Siehe Was bedeutet Privatsphäre und warum ist sie wichtig? )
Wie verhält es sich mit Zulieferern und deren Lieferkettendaten?
Können die Daten eines Halbzeuges/Teilproduktes in die Lieferketten-Blockchain (des übergeordneten Produkts) eingebettet bzw. übertragen werden?
Wie verhält es sich mit den Zulieferern zur Herstellung des Halbzeuges bzw. Teilproduktes?
Das bedeutet, dass die Akteure und Teilnehmer an einer Lieferkette unterschiedliche Informationen zu verschiedenen Zeiten einsehen wollen bzw. müssen. Nicht Jeder muss alles Bisherige wissen.
Daraus folgt, dass irgendwie kontrolliert werden sollte, wer wann welche Informationen einsehen und fortschreiben darf. Wie kann sichergestellt werden, dass derjenige ein Datum (Singular von Daten) fortschreibt, der dazu zu diesem Zeitpunkt berechtigt ist? Wie kann ein Datum korrigiert werden, nachdem festgestellt wurde, dass es falsch geschrieben wurde? Wer darf wann was korrigieren?
Der aufmerksame Leser erkennt, dass es jede Menge Fragen gibt, die geklärt werden müssen. Dies war nur eine kleine Auswahl von Fragestellungen.
Datenmengen / Skalierung
Ein weiteres Problem bei Lieferketten sind die Massen von Daten, die anfallen. Fragen, welche Daten überhaupt gespeichert werden sollen/müssen, fallen sofort auf. Aber wie verhält es sich, mit der Speicherdauer der Daten?
Wie viele Daten verkraftet das Netzwerk? Denn eines steht außer Frage: Eine Blockchain ist eine langsame Datenbank. Je dezentralisierter eine Blockchain ist, umso mehr Herausforderungen gibt es bei der Skalierung.
Das Blockchain-Trilemma
In den letzten Jahren haben sich viele Blockchain-Projekte mit dem als Skalierbarkeitstrilemma bekannten Problem auseinandergesetzt. Ein gesundes Gleichgewicht zwischen Skalierbarkeit, Sicherheit und Dezentralisierung zu finden, ist nachwievor eine Herausforderung.
Eine dezentrale Blockchain mit hoher Sicherheit skaliert schlecht. Eine sichere Blockchain mit nur wenigen Knotenrechnern (z.B. PoA im Ethereum Rinkeby Testnet) ist nicht dezentral. Weniger Dezentralität verlangt mehr Vertrauen in die zentralen Akteure.
Soll eine Lieferketten-Blockchain skalieren können, so ist deren Knotenrechnerzahl zu begrenzen, damit die Rechner schneller miteinander sich bzgl. der neuen Transaktionen und Blöcke austauschen können. Ein Proof-of-Authority-Konsensalgorithmus wäre eine Lösung. Dann ist aber diese Blockchain nicht dezentral und vermutlich nicht öffentlich.
Sofern Nutzer über Handy-Apps und nur lesend auf die Blockchain-Daten zugriffen, wäre dies kein Problem. In diesem Szenario würden die Apps mit zentralen Servern kommunizieren, um Daten aus der Konsortial-Blockchain zu erhalten. In diesem Fall ist die Frage berechtigt, ob nicht auch eine dezentrale Datenbank, die besser skaliert, ausreichend wäre. Datenzugriffe sind bei dezentralen Datenbanken schneller und alte Daten könnten einfacher gelöscht werden.
Transparenz- und Privatsphäre-Anforderungen lassen sich auch mit dezentralen Datenbanken umsetzen. Dazu bedarf nicht zwangsläufig einer öffentlichen Blockchain.
Skalierung, Teiltransparenz und Privatsphäre durch Sidechains
Sidechains sind eigene Blockchains, die zu bestimmten Zeitpunkten Daten aus der Hauptkette übernehmen und deren Weiterverarbeitung im kleinen Kreis regeln. Zu einem späteren Zeitpunkt wird ein Zwischenergebnis oder das Endergebnis wieder in die Hauptkette geschrieben.
Sidechains (Seitenketten) ist ein Skalierungsansatz. Aufgrund einer geringen Zahl von Akteuren kommen Seitenketten schneller zu einem Konsens. Sie sind aber auch zentraler als die Hauptkette.
Da die Seitenkettendaten nur den Akteuren der Sidechain bekannt sind, erhöht dies die Privatheit der Daten. Nach Abschluss der Verarbeitung in der Seitenkette wird das Ergebnis öffentlich nachvollziehbar in die Hauptkette geschrieben.
Vorausgegangen sind Prozesse, dass alle Teilnehmer einer Seitenkette mit dem Endergebnis einverstanden sind. Der Konsensalgorithmus in der Seitenkette muss zudem Verfahrensweisen vorhersehen, wenn einzelne Akteure der Seitenkette ihre Mitarbeit einstellen oder falsche Informationen verbreiten.
Fazit
Lieferkette trifft Blockkette?
Lieferketten und Blockketten eignen sich gegenwärtig nicht für längerfristige Beziehungen. One-Night-Stands sind nicht ausgeschlossen und werden auch versucht. Aber über den Affärenstatus kommen beide gemeinsam nicht hinaus.
Der Grund
Eine einzelne und bitcoin-ähnliche Blockchain-Architektur zur Abbildung von Lieferketten ist keine gute Lösung.
Die Kombination mit Seitenketten und anderen Skalierungsmechanismen erhöht die Datenraten, stösst aber auch an Grenzen.
Eine Blockchain im herkömmlichen Sinne eignet sich daher nur begrenzt zur datentechnischen Abbildung von Lieferketten. Besser skalieren Blockchains pro Produkt, ähnlich dem Prinzip, welches von Nano verwendet wird.
Andere Blockchain-ähnliche oder Nachfolge-Architekturen, egal ob Hash-Graph, Spectre oder direkt-azyklische Graphen eignen sich besser für Massendatenverarbeitungen. Ob diese Architekturen sich besser für Lieferketten eignen, war nicht Gegenstand dieses Artikels.