Ethereum – die Vertrauensmaschine

 

Ethereum ist eine 2011 entstandene Blockchain-Technologie, deren Token (»Ether«) seit seiner Auflage nach dem Bitcoin die zweitmeist gehandelte Kryptowährung der Welt ist. Ethereum ist darüber hinaus die einzige Blockchain, die sowohl die Ausführung von Code während der Konsensfindung erlaubt (»Smart Contracts«) als auch von so vielen Nodes weltweit gespiegelt wird, dass sie als hinreichend dezentral und damit mathematisch, wirtschaftlich, juristisch und regulativ unkompromittierbar angesehen werden kann. Damit hat sich Ethereum trotz seiner über die Jahre ans Licht getretenen Nachteile – schwache Skalierbarkeit, kompliziertes Gebührenverfahren, ökologisch fragwürdiger Proof of Work-Konsens und eher rudimentärer Bytecode-Interpreter – zu einem Quasistandard für die Entwicklung dezentraler Applikationen herauskristallisiert.

   

Die wahre Stärke von Ethereum steckt nicht unbedingt in seiner gegenwärtigen Struktur oder seinen Features. Sie liegt in der Offenheit, der überwältigenden Akzeptanz, der extrem aktiven Community mit kreativem, florierendem Ökosystem, der Stabilität und bislang ungebrochenen Unkompromittierbarkeit und Sicherheit. Ganz zu schweigen von dem Vertrauen, das unzählige Marktplätze, DeFi-Plattformen, DAO-Anbieter, Krypto-Börsen, Stablecoins, Tool-Anbieter, Contract-Deployer und Endnutzer dem Netzwerk und der Technologie entgegenbringen. Es mag Blockchain-Technologien geben, die Aspekte besser umsetzen als Ethereum. Bis heute aber bleiben sie alle den Nachweis von entweder Dezentralisierung, Akzeptanz oder Sicherheit schuldig.

   

Ethereum ist mehr Protokoll als Netzwerk, sein Mainnet lediglich eine global laufende Vertrauensmaschine, die demonstriert, wozu die Technologie in der Lage ist. Es existieren mehrere auf Protokollebene kompatible Clients (Geth / Parity OpenEthereum / Besu), mit denen man eigene Ethereum-Nodes oder sogar private Netzwerke betreiben kann.

   

Für die ĐePA entschieden wir uns schon während der Evaluationsphase angesichts des angenommenen Transaktionsaufkommens, selbst ein Netzwerk aus isolierten Ethereum-Nodes für Patientendaten aufzusetzen. Unser »ĐePAnet« besteht derzeit aus 3 Autoritäts-Nodes sowie einem öffentlichen Connector-Node, das auf Grundlage von Parity’s AuRa PoA-Konsensus (Proof of Authority) neue Blöcke schreibt. Das Netzwerk ist unpermissioned angelegt. Jeder kann derzeit ohne Zugangsbeschränkungen weitere Nodes anschließen und Transaktionen senden. Wir gewährleisten die Sicherheit des Netzwerks nicht durch intransparente Zugänge, sondern durch Ownership-Beschränkungen der Smart Contracts der Patientenakten, die nur berechtigten Accounts Zugang zu den Daten in den Akten gewährt.

   

IPFS: Das dezentrale Speichersystem
 

IPFS steht für »interplanetares Filesystem« – und ist damit das vermutlich ambitionierteste Akronym der Welt. Mit IPFS kann man völlig kostenfrei Daten mit jedem anderen Nutzer der Welt teilen. Jeder Node im IPFS-Netzwerk verteilt Datenfragmente so, dass – sofern ein bestimmter Datensatz von hinreichend vielen Nodes oft genug angefragt wird – Daten immer verfügbar sind.

   

IPFS läuft per Default vollständig offline und benötigt keinen laufenden Service für minimale Funktionalität. Mit Hilfe einer einfachen, an POSIX Filesystem-Kommandos angelehnten API lassen sich Dateien und Ordner lokal in einem IPFS Repository speichern. Unter der Haube zerteilt IPFS alle Dateien in Blöcke konstanter Größe, berechnet einen einfachen Hash über den binären Inhalt eines Blocks und verbindet sie mit Hilfe eines Merkle-DAGs zu einer kryptografisch abgesicherten Struktur, die die Integrität und Authentizität der Datei garantiert. Die Blöcke werden in einem lokalen Key Value-Store abgelegt und ihre Prüfsummen in eine verteilte Hash-Tabelle geschrieben.

   

Sobald man einen IPFS-Daemon startet, verbindet man sich mit dem globalen »Schwarm« von anderen IPFS Peers und macht die lokale Hash-Tabelle zum Teil einer global verteilten »Distributed Hash Table«, der DHT. Um eine Datei auszutauschen, teilt man seinem Gegenüber die Content-ID (CID) der Datei mit, die als Hash über den Merkle-DAG ihrer Blöcke gebildet wurde. Die andere Partei versucht nun, eine Route durch das P2P-Netzwerk zu einem Node zu finden, der den Inhalt hinter der Content-ID liefern kann. Zur Stunde Null ist das also der Rechner, der den Content erstmals veröffentlichte. Dafür bittet er alle mit ihm verbundenen Peers, in ihrem lokalen Teil der DHT nachzuschauen, ob sie die Datei haben oder jemanden kennen, der sie hat.

   

Das globale IPFS-Netzwerk besteht aus zehntausenden solcher IPFS-Peers. Daher kann ein Dateiaustausch zwischen zwei eher an den Kanten des Netzwerks liegenden Nodes manchmal 10 bis 20 Minuten dauern. In der Regel sind Route und Daten aber binnen Sekunden gefunden und bereit für den Download.

 

   

Vor der Akte steht die Identität

 

Bevor der Patient seine Akte anlegen kann, eröffnet er in unserer aktuellen Lösung eine lokale Wallet. Wir setzen aus Gründen der Benutzbarkeit und des einfachen Onboardings nicht auf die Kopplung an eine selbstsouveräne Identität des Nutzers, beabsichtigen aber genau das für eine realitätsnähere Lösung. Unsere Ethereum-Wallet ist lediglich ein mit einer Passphrase abgesicherter, lokal gespeicherter Keystore-Container, der den privaten Schlüssel des Patienten enthält – eine 256 Bit lange Zufallszahl.

   

Hier stellen sich bereits Fragen nach Sicherheit, Verlust und Wiederherstellbarkeit des Schlüssels und Benutzbarkeit. Wir speichern den (verschlüsselten) Keystore der neuen Wallet derzeit im Local Storage des Browserfensters und bieten keine für den Nutzer sichtbare Backup-Funktionalität an. Außerdem generieren wir die Schlüssel mit Hilfe von aus Javascript geladenen Funktionen. Wenngleich das vermutlich jede web-basierte dApp ähnlich handhabt, kann dies ein potenzieller, wenn auch recht unwahrscheinlicher Angriffsvektor für eingeschleusten Code sein. Wir bitten um Nachsicht, dass wir diese recht offensichtlichen Probleme für unsere Erstimplementierung vernachlässigen: Unzählige Projekte (Metamask, Fortmatic, Authereum, Jolocom, 3box) entwickeln bereits generische Lösungen für diese Problematik und unsere dApps werden demnächst zu mindestens einem dieser Projekte kompatibel sein.

   

Vertrauensvorschuss Gas-Gebühr

 

Um überhaupt mit der Blockchain interagieren zu können, benötigt man ein minimales »Guthaben«, damit man die Gebühren für die Ausführung von Smart Contracts während der Konsensfindung bezahlen kann. Sobald der Nutzer eine Wallet erstellt hat, fordern wir automatisch im Hintergrund einen kleinen Betrag unserer eigenen virtuellen Währung an, mit dem der Nutzer das Gas für Transaktionen auf dem ĐePAnet »bezahlt«. Auch dieser Schritt ist bislang ungesichert und gehört zu den bekanntesten Zugangsbeschränkungen und Onboarding-Schwierigkeiten in der Ethereum-Welt. Die hierfür notwendigen »ĐePA-Tokens« sind selbstverständlich keinen realen Euro wert und unterliegen auch nicht der typischen Dynamik sogenannter Cryptowährungen. Es gibt in einem Proof of Authority-Netzwerk keinerlei Mining-Inzentivierung zur Schaffung neuer Tokens, keinen Einsatzzweck als Währung und auch keine Börse, an der man einen ĐePA-Token gegen Dollar wechseln könnte. Der Token-Aspekt im ĐePAnet ist lediglich ein Implementierungsdetail von Ethereum mit praktischen Implikationen für Benutzbarkeit und Zugangsbeschränkung.

   

Für die Nutzung von dApps auf dem Ethereum Mainnet benötigt man normalerweise »echtes« Geld. Wir wählten für unser privates ĐePAnet einen einfachen, für den Nutzer transparenten und auf privaten Netzen absolut üblichen Hintergrundprozess (in der Blockchain-Terminologie Faucet genannt). Diese sogenannte »ĐePAnet-Faucet« verschenkt gewissermaßen Geld an jeden, der sich eine dezentrale Patientenakte anlegen möchte. Wollte man die Patientenakte auf dem Mainnet betreiben, müssten Patienten dieses Guthaben selbst mitbringen (oder ein sogenanntes Gas Station Network nutzen, in dem wir als Contract-Betreiber initiale Transaktionen vorfinanzieren).

   

Der Patient legt seine Akte selbst an

 

Mit Account und Basisguthaben ausgerüstet, gelangt der Patient auf ein Dashboard, das als Startpunkt für alle weiteren Funktionen dient. Hier kann er eine neue Akte anlegen. Derzeit delegieren wir diesen Vorgang an einen zentralen Registrierungs-Contract, der eine neue Instanz eines Patientenakten-Contracts erzeugt und dessen Eigentümer-Aspekt während derselben Transaktion an den Account des Patienten überträgt. Die Registrierung kann somit die öffentlichen Adressen der Patienten mit ihren Akten assoziieren, um sie später leicht wiederfinden und auf Änderungsereignisse reagieren zu können.

 

 

Mit Hilfe von ECIES leiten wir aus dem privaten Schlüssel des Patienten einen öffentlichen Schlüssel ab, mit dem andere Teilnehmer Dokumente für den Patienten verschlüsseln können. Weiterhin erzeugen wir eine leere, zum HL7/FHIR4-Standard kompatible Dokumentenstruktur, die die Stammdaten des Patienten repräsentiert. Schlüssel und Rumpfdokument legen wir in einem neuen Verzeichnis ab, das mit der Signatur des Patienten über seine öffentliche Adresse benannt ist. So lässt sich jederzeit sicherstellen, dass der Inhalt dieses Verzeichnisses unzweifelhaft zum Patienten gehört. Die von IPFS generierte Content-ID dieses Ordners verankern wir mit Hilfe einer einzigen Transaktion auf dem Patienten-Contract.

   

Der Patient kann anschließend seine Akte mit Stammdaten ergänzen. Wir unterstützen der Einfachheit halber nur seinen Namen, Geschlecht und Geburtstag – alle diese Daten werden in unserem Modell vom Patienten selbst hinterlegt, könnten bei Bedarf aber auch von einer anderen autoritativen Entität (wie z.B. einer Krankenkasse) eingetragen werden.

   

Schreiben darf nur der Eigentümer

 

Hier zeigt sich bereits das Dilemma der Datenhoheit: Da keine Entität außer dem Patienten selbst unmittelbaren Schreibzugriff auf die Akte erhalten kann, weil sie dafür das Recht benötigen würde, direkt mit dem Contract des Patienten zu interagieren, müssen jegliche Schreibtransaktionen, die nicht von ihm selbst ausgehen, zunächst vom Patienten bewilligt werden.

   

Jede Partei, die etwas an der Akte des Patienten ändern möchte, muss dem Contract des Patienten daher Änderungen vorschlagen. Hierfür erzeugt sie zunächst ein Dokument mit den zu ändernden oder hinzuzufügenden Daten, verschlüsselt es mit dem öffentlichen Schlüssel des Patienten und veröffentlicht es über IPFS. Anschließend ruft die Partei eine öffentliche Funktion auf dem Contract des Patienten auf, die die Content-ID des Änderungsvorschlags als Event loggt. Die App des Patienten bemerkt dank dieser Onchain-Events, dass ein neuer Änderungsvorschlag vorliegt und kann entsprechend reagieren.

   

Der Patient kann den Inhalt des Änderungsvorschlags entschlüsseln, ihn begutachten und ihn ggf. zu seiner Akte hinzufügen. Dieser Schritt ist dank IPFS einfach: Das neue Dokument wird innerhalb des IPFS-Verzeichnisses des Patienten abgelegt und die dabei neu entstandene Content-ID auf dem Smart Contract verankert. Alle bislang gespeicherten Daten bleiben von der Änderung unberührt.

   

Eine gemeinsame Vertrauensbasis

 

Um den Aufwand für Patienten gering zu halten, erlaubt es die Patientenakte, bestimmten Ärzten zu »vertrauen«. Ärzte können ein öffentliches Profil – sozusagen das dezentrale Abbild ihres Heilberufs- oder Praxisausweises – in einem speziellen Registrierungs-Contract verankern und sich dort (das ist aber noch nicht Bestandteil unserer Demo) von einer anderen Autorität, z.B. Krankenkassen oder Bundesverbänden bescheinigen lassen, dass sie tatsächlich ein Arzt sind. Die hierfür am besten geeignete Technologie sind Verifiable Credentials, die bestimmte Eigenschaften von Entitäten bescheinigen können, ohne andere Eigenschaften oder sogar die wahre Identität des Claim-Eigentümers preiszugeben. Ein Patient kann anhand dieser Registrierung überprüfen, dass ein Account, mit dem er interagieren möchte, eine verifizierbare »Arzt«-Eigenschaft besitzt und diesem Account ggf. unmittelbar vertrauen.

   

Wir realisieren dieses Trust-Verhältnis mit Hilfe einer Bekanntmachungsphase zwischen Patient und Arzt. Sobald der Patient die Praxis eines Arztes betritt (oder virtuell mit ihm in Verbindung tritt), scannt er einen QR-Code, der die öffentliche Adresse des Arztes enthält. Er fragt im Registrierungs-Contract für Ärzte nach dem öffentlichen Stammdaten-Profil, das der Arzt auf IPFS hinterlegt hat und überprüft die Vertrauens-Claims des Arztes. Sofern die Informationen plausibel sind, verankert er das Vertrauensverhältnis zu dem Arzt in seinem eigenen Patientenakten-Contract, sodass er und seine App wissen und jederzeit überprüfen können, dass dieser Arzt vertrauenswürdig ist.

   

Sobald das Vertrauen zwischen Arzt und Patient hergestellt wurde, sendet der Patient dem Arzt eine vollständige bzw. granulare Kopie seiner Akte, indem er alle Daten mit dem öffentlichen Schlüssel des Arztes verschlüsselt und dem Arzt die entsprechende Content-ID freigibt. Da diese Kommunikationsrichtung keine Vertrauensbasis erfordert, setzen wir auf Off-Chain Benachrichtigungen in Form von IPFS / libp2p »PubSub«-Messages. In der Praxis stellt man recht schnell fest, dass solche Nachrichten aufgrund der Mesh-artigen Struktur des IPFS-Netzwerkes nicht völlig zuverlässig zwischen den Peers vermittelt werden können, gerade wenn sich Teilnehmer in einem schwer zu erreichenden Netzwerk (z.B. einem Mobilfunknetz) befinden. Alternativen, die wir daher evaluieren sind dezentrale Messaging-Dienste wie 3box Messaging, Origin oder P2P Matrix. Theoretisch könnte der Patient während der Bekanntmachungsphase dem Arzt sogar eine E-Mail mit seiner öffentlichen Adresse schicken, aber das widerspräche natürlich dem Konzept der Dezentralität.

   

Sobald sich Arzt und Patient gegenseitig verifizierbar das Vertrauen ausgesprochen haben, kann der Arzt damit beginnen, Daten in die Akte des Patienten einzutragen. Unser eher rudimentäres Arzt-Frontend demonstriert dies mit einem FHIR4-kompatiblen »Immunization«-Dokument: Der Arzt erzeugt innerhalb seines Systems ein neues Dokument mit impfspezifischen Daten, verschlüsselt es mit dem öffentlichen Schlüssel des Patienten und veröffentlicht die entsprechende Content-ID. Anschließend sendet er einen minimalen Hinweis an den Akten-Contract des Patienten, dass ein neuer Eintrag vorliegt. Die App des Patienten bekommt dies früher oder später mit, prüft das Vertrauensverhältnis zwischen Arzt und Patient und hängt das neue Dokument in den IPFS-Verzeichnisbaum der Patientenakte ein. Zuletzt vermerkt die Applikation die dabei entstandene neue Content-ID der Akte als »zuletzt gültige« Fassung im Akten-Contract des Patienten.