Technologische Erwägungen für einen weiterführenden Einsatz

6.12.2018

Was konnten wir im Piloten bereits erreichen?

Zunächst macht es natürlich trotzdem Sinn auf die erreichten Ziele und bereits vorhandenen Vorteile - gerade im Vergleich zu einem analogen Prozess - zu blicken. Diese Funktionsgewinne beziehen sich dabei nicht auf das eigentliche Ziel, die Erprobung der Blockchain, sondern sind quasi Nebenerzeugnisse, die auf dem Weg erreicht wurden.

So wurde die Prozessdigitalisierung beispielsweise als eine unabdingbar benötigte Komponente mit der Pilot-Anwendung vollständig umgesetzt. Auch wenn es noch keinerlei Optimierungen gibt, würde der Prozess digital wie analog funktionieren. Dies haben unsere Teilnehmer bestätigt - und das ohne lästiges manuelles Erfassen der Palettenscheine, sondern mit vollständig digital geleisteten Unterschriften. Ein guter Start!

Dies eröffnet auch gleichzeitig den ersten Funktionsgewinn: Der Saldo zwischen zwei Tauschpartnern ist zu jedem Zeitpunkt verfügbar, nicht erst nach dem periodischen Verarbeiten der gesammelten analogen Palettenscheine. Das heißt hier bereits, dass Entscheidungen über Bewegungen von Paletten an der Rampe live und auf aktuellen Daten getroffen werden können. Wenn ein hoher Saldo existiert, kann dieser beispielsweise durch das aktive Zurückhalten von Leerpaletten schleichend ausgeglichen werden.

Auch das Datenformat wurde im Rahmen des Piloten standardisiert und erprobt. In der Praxis stellen sich gerade hier oft Hürden und vermeintlich unüberwindbare Hindernisse in den Weg. Durch die Nutzung des GS1 EPCIS Formates (mit kleineren Anpassungen für die Blockchain) konnte schnell Konsens gefunden werden. Auch der Blick direkt in die Blockchain und damit auf’s verwendete Datenformat wurde von einigen Projektteilnehmern durchgeführt - alle konnten hierbei die Transaktionen auch ohne Frontend nachvollziehen. Das ist zwar unkomfortabel, unterstreicht aber die Offenheit unserer Lösung und legt den Grundstein für die Auswertbarkeit der Daten.

In dieser Auswertbarkeit liegt unserer Meinung nach, das größte Potential einer solchen vollständig digitalen Lösung. So wären beispielsweise Ringtausch-Szenarien denkbar, bei denen zwischen mehr als zwei Handelspartnern Differenzen bestehen, die kumuliert ausgeglichen werden können. Aktuell basiert die Betrachtung solcher Szenarien auf der vollen Datentransparenz, die wir für den Piloten angenommen haben. Dabei gibt es aber auch alternative Ansätze, wie diese ermöglicht werden können. Unten dazu mehr.

Last but not least: Wir konnten mit 17 Partnern auf Augenhöhe ein Blockchain-Projekt erfolgreich abschließen, welches ungemein stark von der Zusammenarbeit dieser abhängt. Die Blockchain trat, wie hier selbst im Text zu merken, in den Hintergrund, und das ist gut so! Der reibungslose Ablauf für den End-Nutzer zählt. Blockchain ist dabei nur eine Technologie und somit ein Mittel zum Zweck.

Datenmenge

Zunächst sei gesagt, dass die anfallenden Daten mehr als überschaubar sind. Es ist mit einem Volumen von ca. 10MB pro 1000 Tausch-Transaktionen (plus etwas Overhead, Indizes) zu rechnen. Die im Pilot-Betrieb angefallenen Transaktionen würden auch in einem Jahr nur zu etwa 500MB Daten führen.

Das klingt zunächst nicht viel, wenn man jedoch die Anzahl der Netzwerk-Teilnehmer sowie die Zeit entsprechend skaliert, führt dies zu einem nicht zum unterschätzenden Datenvolumen. Eine Hochrechnung der im Lasttest angefallenen Daten (3600 Tauschvorgänge pro Stunde, 86.400 pro Tag und knapp 32 Mio. pro Jahr) zeigt, dass man es schnell mit Gigabyte an Daten, genau gesagt 300GB pro Jahr, zu tun bekommt. Zusammen mit dem Grundsatz der Unveränderlichkeit der Daten führt dies zur Erkenntnis, dass man sich sehr wohl über den Verbleib und Lebenszyklus der Daten Gedanken machen muss.

Teilweiser statt vollständiger Replikation

Ein häufig diskutierter Ansatz, der aktuell nach und nach in eine Vielzahl an Blockchain Technologien mit Enterprise-Fokus Einzug hält, ist die teilweise Replikation von Daten zwischen am Prozess beteiligten Unternehmen. Dies wird beispielsweise in MultiChain 2.0 unter dem Namen „Off-Chain Daten” eingeführt. Kurz gesagt werden hier private Kommunikationskanäle zwischen 2 Knoten beschrieben, die nicht in einer global replizierten Kette veröffentlicht werden müssen.

Dieser Ansatz hat sowohl Vorteile bei Datenvolumen als auch in der Latenz der Transaktionen, da nur der Fingerabdruck der Information global konsistent verfügbar sein muss, die eigentlichen Daten werden später asynchron repliziert. Konkret hätte dies in unserem Palettentausch-Konsortium außerdem den Vorteil, dass das zu erwartende Datenvolumen linear zur Anzahl der eigenen Transaktionen skaliert. Ein multinationales Logistik-Unternehmen kann durchaus mit Datenmengen in Terabyte-Größe umgehen, für eine Gärtnerei, die nur wenige Transaktionen pro Tag und Woche durchführt, ergibt dies jedoch keinen Sinn.

Eine Hochrechnung zwischen einigen am Test teilnehmenden Unternehmen bestätigt diese Annahme und macht eindrucksvoll klar, dass ein passendes Konzept zur Replikation der Daten die Akzeptanz der Technologie deutlich steigern kann.

Lebenszyklus einer Enterprise Blockchain

Trotz möglicher Optimierungen durch Teil-Replikation der Daten muss man sich früher oder später um den Lebenszyklus Gedanken machen. Eine Blockchain bleibt eine Blockchain, mit aufeinander aufbauenden Blöcken und Validierung bis hin zum ersten, dem Genesis Block. Ein einfaches Löschen oder Archivieren von alten Daten ist hier nicht möglich.

Der einfachste und gleichzeitig vielversprechendste Ansatz ist simpel. Wie bei einem vollen Notizbuch oder einem zu gut gefüllten Auftragsbuch gehen irgendwann die Seiten aus. Nun ist das bei einer technischen Lösung nicht unbedingt der Fall, die Lösung bleibt jedoch die gleiche. Ein einfacher Übertrag eines Schlusssaldos als Anfangstransaktion in einen neuen Stream und das „Schließen” des alten Streams wäre hierbei das Mittel der Wahl. Eine Kopie der Daten im nicht mehr veränderlichen Stream kann dann mit klassischen Mitteln archiviert oder vorgehalten werden.

Saldenermittlung und Bestandsführung

Das im Piloten erfolgreich evaluierte System übernimmt aktuell die Digitalisierung der heute inhaltlich im Palettenschein enthaltenen Schuldfortschreibung: durch den ungleichen Tausch entsteht eine Schuld, die irgendwann durch Palette oder Geld beglichen werden muss. Allein für diese Funktionalität würde man jedoch noch keine Blockchain benötigen, da die fortgeschriebene Schuld ihren Wert nämlich durch die beidseitige Signatur zwischen den Tauschpartnern gewinnt. Ohne Signatur keine Akzeptanz der Schuld. Die Blockchain stellt heute primär die fehlerfreie Replikation auf beide Seiten bzw. den gegenseitigen Nachweis über diese sicher.

Alternativ könnte man eine digitale kryptografische Verrechnungseinheit (z.B. Paletten-Coin) entweder als erweiterte Schuldfortschreibung (wobei Coins frei generiert werden können) oder als tatsächliche Repräsentation des Geldwertes der Palette (dabei wäre eine zentrale Ausgabe der Coins nötig) nutzen. Eine genauere Betrachtung dieses Themas findet sich bereits im Blog zu Native Assets.

Alternative Technologien und Alternativen im Allgemeinen

Wie bereits bei der Saldenermittlung beschrieben lohnt es sich genauer hinzusehen: Benötigt es beim hier vorliegenden Fall wirklich Blockchain Technologie, um diesen zu lösen? Jein.

Zunächst zum Nein: Nein, denn der größte Zugewinn im Prozess ist die Digitalisierung. Nein, denn Vertrauen kann im aktuellen Fall auch durch gegenseitiges Signieren eines Datensatzes hergestellt werden. Nein, denn selbst Ringtausche würden wahrscheinlich über periodisches Veröffentlichen der eigenen Saldos funktionieren.

Nun behandeln diese Punkte einen wichtigen Grund für den Einsatz einer Enterprise Blockchain nicht – nämlich die dezentrale Zusammenarbeit an Informationen. Diese ist meist nur durch das Gestalten eines alternativen Prozesses zu ersetzen, mit dem alle Teilnehmer einverstanden sind? Das heißt im konkreten Fall: Einen Intermediär finden, der eine Plattform für den Palettentausch bereitstellt und gemeinsam mit Partnern, Kunden, aber auch Konkurrenten dort alle Daten zum Palettentausch zu veröffentlichen. Im Kapitel „Datensichtbarkeit” zeigt sich, dass das vielleicht doch nicht so einfach wird.

Also Ja: Ja, weil ich ohne zentrale Autorität meine angenommene Realität validieren kann. Ja, weil sie ungemein einfache Methoden zur Nachvollziehbarkeit (via Konsortium-Identitäten, siehe unten) der Transaktionen schafft. Ja, weil sie einen geeigneten Rahmen bildet, gemeinsam im Konsortium Regeln zu definieren und durchzusetzen.

Die eigentliche Frage, die sich für mich stellt, ist nicht ob, sondern welche Blockchain-basierte oder -beeinflusste Technologie den richtigen Rahmen für ein Palettentausch-Konsortium stellen sollte. Diese gilt es zu beantworten, denn die Schaffung eines besagten „Palettentauschkonsortiums” allein ist hier bereits eine nicht signifikant genug zu bewertende Veränderung der Realitäten, hin zu mehr Augenhöhe und Kollaboration.

Kostenbetrachtung

Ein Knoten zu betreiben kostet Geld. Da wir für eine sinnvoll funktionierende Blockchain eine gewisse Anzahl laufender Knoten benötigten, muss entweder die intrinsische Motivation hoch genug sein (Datentransparenz, Validieren der Transaktionen) oder ein anderer Anreiz gefunden werden. Diese Betrachtungen werden aktuell in die Überlegungen zur Konsortialbildung eingebracht, denn entweder werden Abrechnungsmodelle auf dieser Ebene gefunden oder es müssen technische Inzentive her.

Administration und Lifecycle

Während der Pilot-Phase gab es im MultiChain Netzwerk nur zwei Admin Knoten mit Mining-Rechten (diese dürfen neue Blöcke an die Blockchain anhängen). In einer Betrachtung für die Zeit nach dem Piloten gilt es eine sinnvolle Größe des Kernnetzwerks mit entsprechenden Mining- und Admin-Rechten zu definieren. Hieraus folgt dann auch, dass wir uns um den Lebenszyklus der Blockchain (bspw. Major Version Upgrade) Gedanken machen müssen. Außerdem ist die Definition der Admin-Rechte und -Pflichten ausstehend (bspw. wie viele Mining-Nodes online sein müssten etc.). Aus den jeweiligen Rechten entwachsen auch Konsortium-kontrollierte Pflichten (bspw. Uptime des Knotens, …). Diese Probleme werden in einer Public Blockchain normalerweise durch Inzentivierung gelöst (bspw. Block Reward) und müssen in einem privaten Setup durch vertragliche Rahmenbedingungen geschaffen werden.

Datensichtbarkeit

Wie im Schlussfragebogen ersichtlich haben sich viele Projektteilnehmer gegen eine vollständige Transparenz, wie wir sie aktuell ausgeprägt haben, ausgesprochen. Diese kontroverse Diskussion gehört zu den meisten Blockchain-Projekten und war daher bereits während des Lösungs-Designs vorhanden. Wir haben uns zunächst trotzdem aktiv für eine vollständige Transparenz entschieden, um den möglichen Mehrwert der Verfügbarkeit von Daten zu zeigen.

Zunächst bleibt anzumerken, dass uns Blockchain als dezentrale Technologie erst die Möglichkeit gibt, über Datensichtbarkeit außerhalb von Peer-to-Peer Integrationen nachzudenken. Im Falle eines zentral betriebenen Netzwerkes hat der Intermediär immer volle Sichtbarkeit auf alle Daten. Es ist also als Zugewinn an Eigenbestimmung und Schutz sensitiver Daten zu sehen, dies als Option zu haben.

Eine Möglichkeit für beschränkte Transparenz ist die oben erwähnte Nutzung von Privaten Side-Chains/ Off-Chain Daten, die nur zwischen den jeweils beteiligten Parteien geteilt und nur logisch bei Bedarf gegen eine globale Transaktionskette geankert werden. Abhängig von der gewünschten und erlaubten Transparenz wäre es dann trotzdem möglich, Szenarien wie Ringtausche zu ermöglichen. Dazu müsste beispielsweise lediglich zyklisch ein Publizieren der Salden erfolgen. Einzelne Transaktionen können so zwischen den jeweiligen Partnern “geheim” bleiben.

Prozessoptimierungen

Das Feld der Prozessoptimierungen ist so wenig eingegrenzt wie mannigfaltig in der Ausprägung. Eine Digitalisierung ist meist ein Türöffner für sinnvolle und weniger sinnvolle Änderungen und Optimierungen, die es immer gegen konkreten Nutzen abzuwägen gilt. Im Pilotprojekt wurde eine technische Basis geschaffen, um Palettenbewegungen zu dokumentieren. Dies ermöglicht allerdings nur eine quantitative, keine qualitative Betrachtung des Palettentausches.

Ein interessanter Aspekt ist eine mögliche Serialisierung der Palette, über RFID Chip oder Code, um von einer Palette zu der Palette überzugehen. Dies würde es ermöglichen die konkrete Bewegung der einzelnen Palette zu verfolgen um dann Optimierungen wie beispielsweise eine Reduzierung von Leerfahrten, produktive Tauschvorgänge etc. zu ermöglichen.

Fazit

Abschließend bleibt zu sagen, dass die eingesetzte Technologie - Blockchain bzw. konkreter MultiChain - zu keiner Projektphase ausschlaggebende Diskussionen oder Situationen nach sich zog. Es waren vielmehr die kontroversen Diskussionen zum Design des Prozesses, der Datenmodelle, Abläufe und Interaktionskanäle (Frontend), die uns manchmal am Erfolg des Projektes zweifeln ließen. Es muss daher eine holistische, umfassende Sicht auf den Gesamtprozess, nicht nur auf die Technologie, erfolgen. Wenn die benötigten Rahmenbedingungen klar sind, ist die Technologie nur noch Kür.

SAP

Zurück zur Übersicht