Private Blockchain: Wie Unternehmen eine überprüfbare Historie organisieren

Was ist eine Private Blockchain?

Eine Private Blockchain ist ein Blockchain-Netzwerk mit organisatorisch begrenzter Teilnahme und festgelegter Kontrolle über den Betrieb. Ein Unternehmen oder ein definierter Betreiberkreis bestimmt die Teilnahmebedingungen.^[2]

Die zugelassenen Knoten führen das Register nach vereinbarten Regeln fort. Blöcke sind kryptografisch miteinander verknüpft; das Netzwerk regelt, welche neuen Einträge in welcher Reihenfolge zum akzeptierten Stand gehören.^[1]

Für diesen Beitrag bezeichnet „privat“ den abgegrenzten Betreiber- und Teilnehmerkreis. Davon zu unterscheiden sind die konkreten Berechtigungen: NIST bezeichnet ein Netzwerk als permissioned, wenn nur autorisierte Teilnehmer Blöcke veröffentlichen dürfen. Wer Daten einreichen und wer sie lesen darf, wird gesondert festgelegt. Ein solches Netzwerk kann bestimmte Informationen auch öffentlich zugänglich machen.^[1]

Für eine Anwendung im Unternehmen ist deshalb die Bezeichnung allein noch keine ausreichende Beschreibung. Entscheidend ist die konkrete Verteilung der Rechte und Verantwortlichkeiten.

Ein Unternehmen kann das Netzwerk selbst betreiben

Eine Private Blockchain setzt nicht voraus, dass mehrere voneinander unabhängige Unternehmen ihre Infrastruktur gemeinsam betreiben. Auch ein einzelnes Unternehmen kann den Betrieb und die Zulassung der Teilnehmer kontrollieren. NIST beschreibt ausdrücklich die damit verbundene Vertrauensabhängigkeit: Wenn eine Stelle bestimmt, wer Blöcke veröffentlichen darf, müssen die Nutzer dieser Stelle in dieser Hinsicht vertrauen.^[1]

Mehrere Knoten unter derselben Leitung verteilen technische Aufgaben, schaffen aber allein noch keine unabhängige Kontrolle. Für die Bewertung zählt daher neben der Zahl der Knoten auch, wer ihre Konfiguration, Zugänge und Änderungen kontrolliert. Eine organisatorisch getrennte Prüfstelle kann eine andere Rolle übernehmen als ein weiterer Server desselben Betreibers.

Die Fachliteratur zu Blockchain in Einkauf und Supply Chain behandelt Entwicklung und Betrieb entsprechend als eigene Gestaltungsentscheidungen. Eigenentwicklung, Kooperation und Fremdbezug stehen neben Fragen nach Partnern, Zugriffsrechten und Blockchain-Typ.^[2] Daraus folgt keine allgemeine Empfehlung für eine Eigenentwicklung. Es macht jedoch deutlich: Die Entscheidung für Blockchain legt das Betriebsmodell noch nicht fest.

Lesen, einreichen und bestätigen sind verschiedene Rechte

Für das Verständnis einer privaten Blockchain helfen drei getrennte Fragen:

Eine eingereichte Transaktion ist noch kein bestätigter Bestandteil der Blockchain. NIST trennt die Einreichung von Transaktionen, ihre Aufnahme in Blöcke und den Konsens über den Registerstand.^[1]

Diese Unterscheidung wird im Betriebsalltag leicht übersehen: „bestätigt“ kann sich auf einen technischen Eintrag beziehen oder auf eine fachliche Entscheidung. Der Anwendungskontext muss erkennen lassen, welche Bedeutung gemeint ist.

Konsens legt fest, welcher Registerstand gilt

Das Konsensverfahren beantwortet vereinfacht die Frage: Nach welchen Regeln akzeptiert das Netzwerk den nächsten Stand seines Registers? Dazu gehören die Prüfung zulässiger Einträge und die Abstimmung über ihre Aufnahme und Reihenfolge. Verschiedene Verfahren lösen diese Aufgabe unter unterschiedlichen Annahmen über Teilnehmer, Fehler und Angreifer.^[1]

Konsens bedeutet deshalb nicht automatisch eine einfache Mehrheitsabstimmung aller Nutzer. Ebenso wenig setzt eine Private Blockchain das Mining-Verfahren von Bitcoin voraus. Bei einem abgegrenzten Teilnehmerkreis können andere Verfahren eingesetzt werden. Die Beschreibung einer konkreten Implementierung muss zum tatsächlich verwendeten Verfahren passen.

Für einen Anwender lässt sich die praktische Frage auch ohne Offenlegung des Quellcodes stellen: Wann gilt ein eingereichter Eintrag als bestätigt, wie wird dieser Zustand angezeigt, und was geschieht, wenn die dafür notwendigen Knoten nicht verfügbar sind? Das sind Fragen nach dem beobachtbaren Verhalten des Systems.

Beispiel: Eine Übergabe wird dokumentiert und später korrigiert

Das folgende Beispiel ist fiktiv. Es beschreibt eine mögliche Anwendung und keine festgelegte Implementierung von 420+.

Ein Betrieb übergibt das Bauteil B-73 an einen nachgelagerten Arbeitsbereich. Zum Vorgang U-118 werden drei aufeinanderfolgende Ereignisse erfasst:

Für dieses Beispiel sei festgelegt, dass die Einträge mit ihrem Vorgangsbezug in das Register aufgenommen werden und Korrekturen als neue Einträge erfolgen. Die ursprüngliche Aussage bleibt erhalten. Eine aktuelle Ansicht kann die berichtigte Kennung anzeigen und zugleich den Weg von der ursprünglichen Angabe zur Korrektur zugänglich machen. Dieses Aufzeichnungsprinzip erläutert der Beitrag zum Append-only Log.

Die technische Bestätigung des ersten Eintrags bedeutet nur, dass die Bereitstellungsmeldung nach den Netzwerkregeln aufgenommen wurde. Sie ersetzt nicht die Übernahmeerklärung des empfangenden Bereichs. Ebenso beweist die Aufnahme der Korrektur nicht, dass die neue Kennung fachlich richtig ist. Dafür bleiben der zugrunde liegende Beleg und die zuständige Prüfung maßgeblich.

Ein bestätigter Eintrag ist noch keine bestätigte Übergabe. Die Blockchain hält den dokumentierten Vorgang fest; welche Handlung daraus folgt, bestimmt das fachliche Prozessmodell.

Was eine externe Spiegelung zusätzlich prüfbar macht

Im Beispiel könnte eine externe Stelle die Blockfolge und die zugehörigen Hashwerte fortlaufend übernehmen. Sie besitzt damit einen Vergleichsbestand außerhalb des laufenden Systems des Betreibers. Soll sie später eine vorgelegte Historie prüfen, müssen Umfang, Herkunft und Schutz dieses Bestands feststehen.

Der Unterschied ist konkret: Ohne eigenen Vergleichsbestand sieht die Stelle zunächst die Historie, die ihr aktuell vorgelegt wird. Mit einem ausreichend geschützten früheren Stand kann sie prüfen, ob die vorgelegten Daten dazu passen. Welche Daten durch welchen Hashwert gebunden werden und wie der Vergleich erfolgt, muss dafür definiert sein. Die kryptografische Grundlage erläutert Hash-Verkettung.

Eine solche Spiegelung macht die externe Stelle nicht automatisch zu einem Knoten, der neue Blöcke mitbestätigt. Beobachten und vergleichen ist eine andere Aufgabe als die Mitwirkung am Konsens. NIST nennt die Einbindung von Prüf- und Aufsichtsstellen als mögliche Nutzung permissionierter Netzwerke; deren konkrete Rolle bleibt eine Gestaltungsentscheidung.^[1]

Auch die Übertragung selbst braucht eine erkennbare Grenze: Bis zu welchem bestätigten Stand reicht die Spiegelung? Gibt es Unterbrechungen? Welche Teile der Historie lassen sich mit dem vorhandenen Bestand tatsächlich vergleichen? Ein Prüfbericht sollte diese Reichweite nennen. Die Zusammenstellung der erforderlichen Daten, Referenzen und Prüfschritte behandelt Externe Datenverifikation.

Integrität der Historie und Richtigkeit des Inhalts bleiben getrennt

Eine kryptografisch prüfbare Aufzeichnung kann eine falsche ursprüngliche Aussage enthalten. Wurde bei U-118 irrtümlich die Übernahme gemeldet, macht ihre Aufnahme in einen Block daraus keine tatsächlich erfolgte Übergabe. NIST beschreibt diese Grenze bei der Übernahme von Informationen aus der realen Welt als Oracle-Problem.^[1]

Ebenso wenig belegt eine konsistente Historie, dass sämtliche relevanten Vorgänge erfasst wurden. Eine nie eingereichte Handlung hinterlässt nicht allein deshalb eine erkennbare Lücke, weil andere Handlungen in einer Blockchain stehen. Vollständigkeit braucht einen definierten Erfassungsumfang und geeignete Abgleiche.

Auch „unveränderlich“ ist als absolute Zusage ungeeignet. NIST unterscheidet die Erkennbarkeit und Erschwerung von Manipulationen von einer uneingeschränkten Unveränderlichkeit. NIST beschreibt für permissionierte Netzwerke den Fall, dass der Betreiber oder Betreiberverbund durch die Kontrolle über die Zulassung und den Ausschluss von Knoten, die Blöcke veröffentlichen, auch bereits vorhandene Blöcke auf regulärem Weg ersetzen kann.^[1] Ob und unter welchen Bedingungen solche Eingriffe möglich sind, ist an der jeweiligen Architektur zu prüfen. Schlüsselverwaltung, Zugriffsrechte, Softwareänderungen und der Schutz externer Vergleichsstände bleiben Teil des Gesamtsystems.

Wann der Ansatz einen nachvollziehbaren Zweck erfüllt

Eine Private Blockchain sollte eine konkrete Prüf- oder Koordinationsaufgabe erfüllen. Im Fall U-118 geht es um einen gemeinsam nachvollziehbaren Registerstand und dessen Vergleich mit einem außerhalb des Betreibers aufbewahrten Stand. Ob dieser Aufbau gegenüber einer anderen Registerarchitektur vorteilhaft ist, hängt unter anderem von den Beteiligten, ihren Befugnissen und dem geforderten Prüfverfahren ab.

Die Supply-Chain-Literatur diskutiert dafür etwa die Nachverfolgung von Produkten, Zertifikaten und technischen Informationen über Organisationsgrenzen hinweg.^[2] Solche Anwendungsfelder sind Möglichkeiten, keine Belege dafür, dass jede Lieferkette eine Blockchain benötigt. Die technische Grundlage löst insbesondere nicht von selbst die Zuordnung eines realen Bauteils zu seinem digitalen Datensatz.

Für eine Auswahl helfen fünf Fragen:

• Welcher gemeinsame Registerstand wird benötigt, und von wem?
• Wer kontrolliert die Zulassung und den Betrieb der bestätigenden Knoten?
• Welche Daten werden erfasst, welche nur referenziert und welche für Prüfer zugänglich gemacht?
• Gegen welchen unabhängig geschützten Stand kann eine spätere Darstellung geprüft werden?
• Welche Aussage bleibt nach der technischen Prüfung noch fachlich zu beurteilen?

Private Blockchain bei 420+

420+ verfügt über eine eigene Private Blockchain, die das Unternehmen selbst betreibt. Hashwerte und die vollständige Blockfolge können in Echtzeit an eine externe Stelle gespiegelt werden, beispielsweise an eine Behörde.

Damit lässt sich neben dem betrieblichen System ein externer Vergleichsbestand bereitstellen. Welche Daten eine empfangende Stelle erhält und welche Prüfung sie damit durchführen kann, hängt vom vereinbarten Umfang und Verfahren ab. Die Möglichkeit einer Spiegelung bedeutet nicht, dass jede solche Stelle am Konsens teilnimmt oder dass bereits eine behördliche Anbindung besteht.

Die Ledger-Architektur von 420+ ordnet die Aufzeichnung in den betrieblichen Zusammenhang ein. Für die Beurteilung zählt, welcher Vorgang dokumentiert wird, wie spätere Ergänzungen darauf Bezug nehmen und welchen Stand eine externe Prüfung tatsächlich umfasst.

Eine überprüfbare Historie braucht einen benannten Prüfmaßstab

„Private Blockchain“ beschreibt eine technische und organisatorische Grundlage. Die belastbare Aussage entsteht erst aus dem Zusammenspiel von Registerregeln, erfassten Daten, Zuständigkeiten und Vergleichsbestand.

Beim Vorgang U-118 bleibt deshalb jede Ebene sichtbar: Die Bereitstellung wurde gemeldet, die Übernahme wurde gesondert bestätigt und eine Angabe später korrigiert. Eine Prüfung der Registerhistorie kann die fachliche Prüfung unterstützen. Sie übernimmt nicht deren Entscheidung.