Blockchain ohne Hype: Welche Infrastruktur hinter digitalen Assets steckt

Blockchain ist mehr als Kryptowährung

Wenn über Blockchain gesprochen wird, landet die Diskussion schnell bei Bitcoin, Ethereum oder Kursentwicklungen. Das greift für mich zu kurz.

NIST beschreibt Blockchain grundlegend als verteilt geführtes digitales Register, das Veränderungen nachvollziehbar macht und Manipulation erschweren soll.^[1]

Technisch ist das erst einmal ein anderes Modell dafür, wie Zustand und Eigentum zwischen mehreren Teilnehmern verwaltet werden. Ein digitales Asset ist dabei nicht zwingend eine Kryptowährung. Es kann ebenso einen Anspruch, ein Wertpapier, einen Zugang, einen digitalen Nachweis oder die Repräsentation eines realen Vermögenswerts darstellen.

Die Bank für Internationalen Zahlungsausgleich definiert Tokenisierung beispielsweise als die Erzeugung und Aufzeichnung einer digitalen Repräsentation traditioneller Vermögenswerte auf einer programmierbaren Plattform.^[2]

Wichtig ist dabei: Tokenisierung ist nicht automatisch gleichbedeutend mit einer öffentlichen Blockchain. Sie kann auf unterschiedlichen programmierbaren Plattformen und DLT-Architekturen umgesetzt werden. Die konkrete Technologie hängt vom Anwendungsfall, den beteiligten Parteien und den Anforderungen an Governance, Vertrauen und Kontrolle ab.

Damit wird aus „Blockchain“ plötzlich ein Infrastrukturthema.

Nodes und Validatoren bilden die technische Basis

Ein Blockchain-Netzwerk besteht nicht aus einer einzelnen zentralen Datenbank. Mehrere Nodes halten und prüfen Daten nach den Regeln des jeweiligen Protokolls. Welche Rolle ein Node dabei übernimmt, hängt vom Netzwerk und vom verwendeten Konsensmechanismus ab.

Bei Ethereum beispielsweise führt ein Node Client-Software aus, kommuniziert mit anderen Nodes und verifiziert Daten anhand der Protokollregeln. Seit dem Wechsel auf Proof of Stake besteht ein Ethereum-Node aus einem Execution Client und einem Consensus Client; ein Validator kann zusätzlich aktiv am Konsens teilnehmen.^[3]

Der gültige Zustand entsteht dabei nicht dadurch, dass jeder Node einfach „mit abstimmt“. Validatoren nehmen aktiv am Konsens teil, während andere Nodes Blöcke und Zustandsänderungen unabhängig anhand der Protokollregeln verifizieren.

Aus klassischer Infrastrukturperspektive ist das gar nicht so exotisch: Betriebssystem, Storage, Netzwerk, Monitoring, Updates, Hochverfügbarkeit und Security bleiben dieselben Themen wie bei anderen Plattformen auch. Neu ist vor allem, dass kein einzelnes System allein über den gültigen Zustand entscheidet.

Wer einen eigenen Node betreibt, reduziert zudem die Abhängigkeit von externen RPC-Anbietern. Dafür übernimmt man aber auch den Betrieb selbst: Synchronisierung, Storage-Wachstum, Client-Updates, Monitoring und Absicherung der Schnittstellen.

Wallets verwalten Schlüssel – nicht die Assets selbst

Ein weiteres Missverständnis betrifft Wallets. Bei klassischen, schlüsselbasierten Wallets liegen die Assets nicht „in“ der Wallet. Die Blockchain speichert den Zustand; die Wallet verwaltet beziehungsweise nutzt die kryptografischen Schlüssel, mit denen über ein Konto verfügt und Transaktionen signiert werden können.

Das ist bewusst vereinfacht formuliert: Smart-Contract-Wallets, Multi-Signature-Modelle und andere Account-Architekturen können die Kontrolle auf mehrere Schlüssel oder zusätzliche Regeln verteilen. Das Grundproblem bleibt aber dasselbe: Schlüssel und Berechtigungen werden zu einem zentralen Sicherheitsfaktor.

Für Unternehmen stellen sich deshalb Fragen, die aus anderen Security-Bereichen bekannt sind:

• Wo werden Schlüssel gespeichert?
• Wer darf Transaktionen freigeben?
• Gibt es Mehr-Augen-Prinzipien oder Multi-Signature-Verfahren?
• Wie werden Schlüssel gesichert und wiederhergestellt?
• Wie werden Rollen getrennt?
• Was passiert bei Verlust oder Kompromittierung?

Self-Custody verschiebt damit Verantwortung zum Betreiber. Custody-Dienste lagern einen Teil dieser Verantwortung an einen spezialisierten Anbieter aus. Beides hat technische und organisatorische Konsequenzen.

Smart Contracts machen Assets programmierbar

Der für mich spannendere Teil beginnt dort, wo ein Token nicht nur einen Eintrag repräsentiert, sondern mit programmierbarer Logik verbunden wird.

Ethereum beschreibt Smart Contracts als Programme, die unter einer Blockchain-Adresse liegen und durch Transaktionen ausgeführt werden.^[4]

Damit lassen sich Regeln direkt an digitale Assets koppeln: Wer darf übertragen? Welche Bedingungen müssen erfüllt sein? Welche weiteren Aktionen werden automatisch ausgelöst?

Das ist konzeptionell interessant, weil Datenhaltung und Prozesslogik näher zusammenrücken. Gleichzeitig entstehen neue Risiken: Fehler im Smart Contract sind keine normale Anwendungspanne, wenn reale Vermögenswerte oder irreversible Transaktionen daran hängen. Testing, Code Reviews, Berechtigungsmodelle und Update-Strategien werden deshalb Teil der Infrastruktur.

APIs verbinden Blockchain mit bestehenden Systemen

In der Praxis arbeitet kaum ein Unternehmen direkt auf Protokollebene. Anwendungen kommunizieren über RPC- oder API-Schnittstellen mit Nodes oder spezialisierten Infrastrukturprovidern.

Das ist die Brücke zu bestehenden IT-Systemen: Ein ERP-System kann einen Prozess anstoßen, eine Anwendung den Status eines Assets abfragen oder ein Workflow auf ein Blockchain-Ereignis reagieren.

Genau hier sehe ich viele Parallelen zu klassischer Automatisierung. Auch bei Blockchain-Infrastruktur geht es am Ende um saubere Schnittstellen, Authentisierung, Fehlerbehandlung, Monitoring und nachvollziehbare Prozesse. In meinem Beitrag „Automatisierung im IT-Betrieb: Warum ich zunehmend auf APIs und n8n setze“ beschreibe ich diese Architekturprinzipien unabhängig vom Blockchain-Kontext.

Ob der Node selbst betrieben oder als Service genutzt wird, ist dann eine klassische Make-or-Buy-Entscheidung: Kontrolle und Unabhängigkeit auf der einen Seite, weniger Betriebsaufwand auf der anderen.

Wo Tokenisierung praktisch interessant wird

Tokenisierung wird interessant, wenn mehrere Parteien einen gemeinsamen, programmierbaren Zustand benötigen und die Übertragung eines Assets mit Regeln oder weiteren Transaktionen verbunden werden soll.

Die BIS nennt beispielsweise programmierbare Plattformen, auf denen digitale Repräsentationen von Geld und anderen Vermögenswerten ausgegeben, übertragen und abgewickelt werden können. Potenzielle Vorteile liegen unter anderem in effizienteren Abläufen, gleichzeitig betont die Institution aber auch Governance-, Risiko- und Interoperabilitätsfragen.^[2]

Technisch denkbar sind zum Beispiel:

• digitale Wertpapiere oder Beteiligungen,
• tokenisierte Forderungen oder Ansprüche,
• digitale Eigentums- und Herkunftsnachweise,
• automatisierte Abwicklung zwischen mehreren Parteien,
• Zugangs- und Nutzungsrechte,
• Verknüpfung von Zahlung und Asset-Transfer.

Aber nicht jeder Prozess braucht eine Blockchain oder überhaupt DLT. Wenn eine einzige vertrauenswürdige Stelle alle Beteiligten kontrolliert und eine normale Datenbank dasselbe Problem einfacher löst, ist eine verteilte Ledger-Architektur häufig unnötige Komplexität.

Was ich technisch wirklich relevant finde

Für mich wird Blockchain dann interessant, wenn man sie nicht als Anlageklasse betrachtet, sondern als mögliche Infrastruktur für digitale Eigentums- und Transaktionsmodelle.

Die Fragen ähneln dann sehr stark anderen IT-Plattformen:

• Wer betreibt die Infrastruktur?
• Wo liegen die kritischen Schlüssel?
• Wie werden Schnittstellen abgesichert?
• Welche Abhängigkeiten bestehen zu externen Providern?
• Wie wird überwacht und aktualisiert?
• Was passiert bei einem Fehler?
• Wie lässt sich ein System in bestehende Prozesse integrieren?

Genau deshalb passt das Thema für mich auch in einen Infrastruktur-Blog. Unterhalb der Begriffe „Token“, „Wallet“ oder „Web3“ liegen am Ende sehr konkrete technische Entscheidungen.