Wie P2P und Blockchain helfen, das Arbeiten mit wissenschaftlichen Objekten zu verbessern – drei Thesen

Finanzindustrie, Patientenakten, Internet of Things – aus vielen privaten wie öffentlichen Quellen fließen derzeit Millioneninvestitionen in die Erforschung der Blockchain. Diese Grundlagentechnik der Cyberwährung Bitcoin verspricht, einige große Probleme dezentralisiert zu lösen. In diesem Blogposting wird gezeigt, dass Blockchain und P2P-Systeme auch für die Big-Data-Herausforderung digitaler Bibliotheken ein einzigartiges Potenzial besitzen. Das Identifizieren, Beschreiben, Transportieren, Benutzen, Bearbeiten und Versionieren wissenschaftlicher Daten im Netz könnte dadurch viel einfacher werden.

Das Internet ist kaputt – es muss dezentraler werden

Das Internet, wie wir es heute benutzen, hat viele Flaschenhälse, die es anfällig machen für Pannen und – mal mehr, mal weniger subtile – Angriffe. Brewster Kahle, der Gründer des Internet Archive, hat in einem lesenswerten Appell 2015 begründet, warum wir ein dezentraleres Netz brauchen. Einige Pioniere und Prominente des Internets verlangten im Jahr darauf beim Decentralized Web Summit des Internet Archive, über die grundlegenden Strukturen des Netzes neu nachzudenken. Wie ich in diesem Blogposting zeigen will, kann auch das Arbeiten mit digitalen wissenschaftlichen Objekten von dezentralen Ansätzen profitieren, die wir aus P2P-Netzen und aus Crypto-Währungen wie Bitcoin kennen.

Wenn ein Dateisystem “interplanetär” wird…

Unter dem unbescheidenen Namen Interplanetary Filesystem (IPFS) skizzierte Juan Benet 2014 ein verteiltes, versioniertes, content-adressierbares Dateisystem. Für Dateien und strukturierte Sammlungen von Dateien (im Weiteren spreche ich oft zusammenfassend von Objekten) erzeugt IPFS automatisch eine de facto unfälschbare Prüfsumme, einen Hash. Dieser ändert sich, sobald eine Datei geändert wird. Die Objekte können universell anhand dieses Hashes aufgerufen werden. Entscheidend ist hier das “universell”: Werden sie einmal im Dateisystem IPFS zur Verfügung gestellt, können sie auf jedem anderen Rechner benutzt werden, auf dem IPFS installiert ist. (Dazu verwendet IPFS im Hintergrund Bittorrent.)

Ein Beispiel für die Funktionsweise von IPFS

Wenn ich die Grafik unter https://www.tib.eu/typo3conf/ext/tib_tmpl_bootstrap/Resources/Public/images/TIB_Logo_en.png brauche, muss ich hoffen, dass der Server tib.eu auch wirklich online ist – und mir unter der angegebenen URL stets genau das gleiche Bild liefert. Vielleicht habe ich Glück und irgendwo ist eine weitere Kopie online, z.B. https://upload.wikimedia.org/wikipedia/commons/f/f7/Logo_of_the_German_National_Library_of_Science_and_Technology%2C_or_Technische_Informationsbibliothek_%28TIB%29%2C_in_English_language.png – aber ich kann nicht sofort erkennen ob das wirklich exakt das gleiche Bild ist. Das selbe Bild unter https://ipfs.io/ipfs/QmWngwr7TzDJujWKXD282tmpnjZuD7d5JutVaYuoZ9Xq1t wird sich hingegen nie ändern – ich brauche nur den Hashwert zu kennen, also den Bestandteil der URL hinter “ipfs.io/ipfs/”. Der Server ipfs.io ist übrigens nur ein Hilfsmittel für dieses Beispiel, denn eigentlich brauche ich dank IPFS ja überhaupt keinen zentralen Server. Wenn IPFS auf meinen Rechner installiert ist, dann reicht http://localhost:8080/ipfs/QmWngwr7TzDJujWKXD282tmpnjZuD7d5JutVaYuoZ9Xq1t (also der gleiche Objektnamen, nur mit “localhost” statt des Hostnamens eines fremden Servers), und ich sehe die Datei – zumindest solange irgendein Rechner mit dem IPFS-Netzwerk verbunden ist und diese Datei zur Verfügung stellt. Ein interessanter Nebeneffekt: Dateien, die man sonst immer wieder kopiert, weil man sie – selbst auf der gleichen Maschine – in verschiedenen Kontexten verwenden will, existieren nur noch exakt ein mal, sind also nicht nur verwechslungssicher, sondern nehmen auch weniger Speicherplatz und Bandbreite weg.

Content-adressierbare Objekte – nichts Neues

Ändert sich in Git ein Objekt auch nur minimal, dann ändert sich auch dessen Hashwert – ein ideales Konzept, um eine Versionsverwaltung darauf aufzubauen. Die Idee content-adressierbarer Objekte ist spätestens durch den kommerziellen Git-Diensteanbieter Github populär geworden. Github ist eine Plattform zum Speichern, Versionieren und gemeinschaftlichen Bearbeiten von Quellcode und sonstigen Daten. Github ist für diese Funktionen Segen und Fluch zugleich. Ein Segen, weil es das öffentliche Bereitstellen von Daten popularisiert hat, indem es besonders bequeme Möglichkeiten eröffnet, zusammenzuarbeiten, und Dritte dabei zuschauen oder eventuell auch mitmachen zu lassen. Ein Fluch, weil es – als kommerziell erfolgreiches Unternehmen – die ganz oben angedeuteten Probleme eines stark zentralisierten Internets nicht gerade verringert.

Ein Beispiel für das Zusammenarbeiten in Github: Pull Requests

Ein öffentliches Archiv meiner Daten aktuell zu halten ist durch Versionsverwaltungssysteme wie Git einfacher geworden. Ein Befehl (“Push”), und die neue Variante einer gerade von mir bearbeiteten Datei wird in einem von mir angelegten öffentlichen Projekt-Archiv (“Repository”) abgelegt. Dabei wird nicht etwa die alte Datei überschrieben, sondern die neueste Version wird automatisch neben der alten abgespeichert, und mit Versionierungs-Informationen versehen. Für Dritte ist dann schnell nachvollziehbar, wer was wann an dieser Datei geändert hat. Wenn ich will, kann ich mir auch die Kopie eines fremden Repositories abrufen. Dem Urheber kann ich später anbieten, bestimmte Überarbeitungen, die ich an meiner Kopie vorgenommen habe, in sein “Original” zu übernehmen – ein “Pull Request”. Solche Funktionen bequem durchführen zu können, und sogar so, dass sie leicht von Dritten im Browser nachvollzogen werden können – darin liegt eine entscheidende Stärke der Plattform Github.

Gemeinschaftliche, transparente “Buchführung” ohne dass alle einer zentralen Autorität vertrauen müssen – geht das?

Die oben genannten Funktionen von Github setzen ein gewisses Vertrauen in die Betreiber der Plattform voraus. Wenn ich Dateien in ein Repository kopiere, soll für jedermann unzweifelhaft klar sein, dass diese Dateien von mir und niemand anderem kommen. Und das Repository selbst soll dauerhaft unter seinem eigenen Namen abrufbar sein, egal ob und wie sich dessen Inhalt zwischenzeitlich verändert. Über solche Transaktionen von vielen zuverlässig Buch zu führen, so, dass jede Änderung jederzeit für jedermann nachvollziehbar ist – das hat bisher immer ein Vertrauen in irgendeine zentrale Instanz vorausgesetzt.

Bitcoin trat 2008 mit dem Anspruch an, ein Problem dieser Art ganz anders zu lösen. Dreh- und Angelpunkt ist dabei die “Blockchain”, das öffentliche Kontenbuch dieser virtuellen Währung, in der jeder Zahlungsvorgang irreversibel und für alle nachvollziehbar festgehalten wird. Jedermann soll eine Transaktion zur Aufnahme in die Blockchain anmelden können, doch nur in der laufenden Abstimmung zwischen allen Teilnehmern des Systems entscheidet sich, ob und wann die Transaktion in die Blockchain aufgenommen wird. Die Besonderheit des Ansatzes Blockchain: Diese Entscheidung kann nicht einfach von böswilligen Teilnehmern absichtlich verhindert oder beeinflusst werden. (Wie dies bei der Blockchain durch einen “proof of work” oder einen “proof of stake” verhindert werden soll, ist bei Peter Roßbach nachzulesen.)

Blockchains für Spezialaufgaben: Namecoin und Co.

2011, also bereits drei Jahre nach dem Satoshi Nakamoto die Bitcoin-Idee veröffentlichte, startete der erste Fork der Bitcoin-Blockchain: Namecoin. Anders als Bitcoin soll die Blockchain hier nicht dem Aufbau einer weiteren Cryptowährung dienen. Vielmehr sollen die in die Blockchain eingetragenen Datensätze weitere nützliche Informationen enthalten können, die auf diesem Wege irreversibel festgehalten werden. Auch die Entwickler des oben vorgestellten Dateisystems IPFS wollen mittels Namecoin eines Tages sicherstellen, dass Dateien und Objekte von jedermann benannt werden können.

Während die Vergabe eines Hostnamens heute das zentralisierte “Domain Name System” (DNS) voraussetzt, und die Vergabe eines Repository-Namens bei Github zum Beispiel einen Vertrag mit den Betreibern dieser Plattform, könnte dies mittels Blockchain alles ohne zentrale Instanzen geschehen. Mittels einer Blockchain ließe sich dann z.B. festhalten, von wem eine Datei ursprünglich kommt, und wer wann welche Änderung daran vorgenommen hat.

Zeitstempel – Ein Beispiel für Blockchain-basierte Dienstleistungen

Ein Beispiel anhand des TIB-Logos (aus dem Beispiel weiter oben): Mittels eines blockchain-basierten Zeitstempel-Dienstes wie Originstamp können Sie prüfen, ob es die Bilddatei unter https://www.tib.eu/typo3conf/ext/tib_tmpl_bootstrap/Resources/Public/images/TIB_Logo_en.png am 2. Mai 2017 bereits gab. Unter https://app.originstamp.org/s/c18158e5fefadb4ff24318bf9fdd41e446b2939f09bec06dbf56821f5aeb72ce liefert der Dienst dazu einen fälschungssicheren Beweis, den sie auch ohne diesen Dienst überprüfen könnten, d.h. ohne dabei einer zentralen Instanz vertrauen zu müssen. Ein bemerkenswertes Detail: Es reicht den Hashwert zu prüfen, sie brauchen das Objekt selbst nicht zu veröffentlichen – ähnlich wie bei einer notariellen Beglaubigung. Auch dass sich das Dokument zu diesem Zeitpunkt in meinem Besitz befand könnte ich beweisen, indem ich einen entsprechenden Hinweis vor dem Zeitstempel-Vorgang ergänze.

Übertragen auf ein Szenario aus der Forschungs-Infrastruktur: Ein Forschungs-Messgerät, dass sich mit dem Netz verbindet, könnte dabei einen Zeitstempel einholen für alle Daten, die es zwischenzeitlich ausgegeben hat. (Ein gelegentlicher, langsamer Austausch weniger Daten mit einem – leicht ersetzbaren – blockchainbasierten Zeitstempel-Dienst würde dazu reichen; das wäre also selbst für einen Sensor fernab der Zivilisation ein realistisches Szenario.) Damit ließe sich für zweifelsfrei auch im Nachhinein beweisen, welche Daten wann von welchem Sensor erzeugt worden sind – ein Schritt, der dabei helfen könnte, die reproduzierbare Erhebung und Verarbeitung von Forschungsdaten zu unterstützen.

Namensvergabe mit DOI für digitale wissenschaftliche Objekte

Der “Digital Object Identifier” (DOI) ist ein heute weit verbreitetes System zur Vergabe von persistenten Namen an digitale wissenschaftliche Objekte. Die Besonderheit der DOI: Das digitale Archiv (das kann zum Beispiel ein Wissenschaftsverlag oder eine Bibliothek sein) kümmert sich um die Namensvergabe, und sichert gleichzeitig zu, dass das jeweilige Objekt dauerhaft unter diesem Namen erreichbar ist. Ändert sich die URL, aktualisiert das Archiv den jeweiligen DOI-Datensatz, der übrigens auch weitere nützliche Metadaten enthalten kann. Große Konsortien hinter DOI, wie Crossref und DataCite, sorgen dafür, dass dies seit vielen Jahren für verschiedene Objekttypen gut funktioniert.

Beide Konsortien machen in den letzten Jahren zunehmend durch neue, wertvolle Mehrwertdienste auf sich aufmerksam, die sich zum “Kerngeschäft” der DOI-Namensvergabe weitgehend modular verhalten. Beispielhaft ist Crossref DOI Event Data – ein Service, der Erwähnungen von DOIs in der Literatur, aber auch auf diversen Online-Plattformen nachweist und die gesammelten Daten frei zur Verfügung stellt. Die Infrastruktur von Event Data kann und soll auch dazu genutzt werden, neben der DOI auch die Verwendung andere URIs zu verfolgen – dabei könnte es sich z.B. auch um einen Hashwert aus einem P2P-Dateisystem handeln.

These 1: Universelle Objektnamen sollten heute besser von Forschern vergeben werden als von digitalen Archiven

Wie oben gezeigt sind content-adressierbare Objekte geeignet um sicherzugehen dass man das gleiche Objekt vor sich hat. Spätestens Github hat gezeigt, dass man auf dieser Basis ein Versionierungssystem aufbauen kann, das das Teilen von Daten für viele bequem macht, und auch das gemeinschaftliche Bearbeiten von Daten unterstützt. Wenn man diese Namensvergabe ohne ein zentrales Nadelöhr (sei es ein kommerzieller Plattformbetreiber, oder auch ein Konsortium) zur Verfügung stellen kann – umso besser. Mit IPFS und ergänzenden Blockchain-basierten Diensten zeichnet sich diese Möglichkeit ab.

Digitale Archive versuchen, Objekte aus der “privaten Domäne” der Forscher bzw. der “geteilten Domäne”, in der z.B. im Team an den Daten gearbeitet wird, mit möglichst geringem Reibungsverlust in die dritte, öffentliche Domäne zu bekommen. (Vgl. auch Andrew Treloars Data Curation Continuum; in der Abbildungen unten sind meine Ergänzungen in rot hervorgehoben.) Eine automatisierte Namensvergabe für versionierte Objekte, wie sie heute auf Github als einer typischen “geteilten Domäne” praktiziert wird, zu universalisieren – das würde diese Reibung stark verringern helfen.

These 2: Von Namensvergabe plus Archivierung plus x als “Paketlösung” zu einem offenen Markt modularer Dienste

Mit der Vergabe persistenter Namen allein ist die dauerhafte Zugänglichkeit der Objekte noch nicht gewährleistet. Das gilt auch für ein P2P-Dateisystem wie IPFS, denn solange nicht mindestens eine Kopie der Datei auf einem der mit dem Netzwerk verbundenen Rechner zur Verfügung steht ist diese Datei für niemanden verfügbar. Da die Namensvergabe mittels IPFS oder Blockchain nicht zwangsläufig mit der Gewährleistung dauerhafter Verfügbarkeit gekoppelt ist, muss letztere als separate Dienstleistungen angeboten werden. Dafür werden digitale Archive weiterhin als Dienstleister benötigt. Die Archive können ihre Dienste verständlich und berechenbar machen, indem sie gemeinsamen Standards folgen (wie dies bereits heute in Crossref und DataCite geschieht), aber sie können auch Mehrwertdienste anbieten. Auch dies ist nichts neues – Journals kümmern sich z.B. um die Archivierung “ihrer” Artikel, die als solche bestimmte zusätzliche Kriterien erfüllen (“peer reviewed”).

Im Vergleich zu einem DOI-Konsortium ändert sich bei dezentralisierter Namensvergabe lediglich die Schwelle zum Markteintritt. Verträge mit Konsortialpartnern sind nicht mehr zwingend erforderlich. Wer neue Ansätze zur Vergabe von Namen, zur Gewährleistung der Verfügbarkeit oder andere Mehrwertdienste anbieten will könnte das tun – ohne jeglichen Vertrag. Die einzige Voraussetzung wäre das Befolgen der Protokolle des jeweiligen dezentralen Systems.

Dass digitale Archive wissenschaftliche Objekte “besitzen” spielt heute ohnehin immer weniger eine Rolle. Durch einen Namensbestandteil der DOI oder den Hostnamen, unter dem das “Original” erreichbar ist, wird dieser “Besitz” zwar immer noch gekennzeichnet. De facto können diverse wissenschaftliche Objekte heute jedoch an verschiedenen Orten entdeckt oder Kopien davon abgerufen werden. Umso wertvoller wäre es, die Objekte primär anhand ihres Contents zu identifizieren. Das Bearbeiten, Veröffentlichen und Versionieren könnte dann so direkt wie möglich von den jeweiligen Urhebern kontrolliert werden. Ergänzende Dienste (Sammeln und Archivieren, Erschließen, Entdeckbar- und Benutzbarmachen etc.) könnten dann modular von jedermann angeboten werden, mit minimalen Reibungsverlusten zwischen Urhebern und ergänzenden Diensteanbietern, sowie bei den Diensteanbietern untereinander.

These 3: Große Datenmengen leichter wissenschaftlich nutzbar machen ohne APIs und zentrale Hosts

Text- und Datamining über große Datenmengen hinweg gehört mittlerweile zum wissenschaftlichen Alltag in vielen Fächern. Dienste, mit denen sich wissenschaftliche Inhalte entdecken, begutachten oder weiterverarbeiten lassen, werden immer populärer. Angesichts dieser Entwicklungen wäre es wünschenswert, über große, komplexe, dynamisch wachsende Objektsammlungen ähnlich problemlos verfügen zu können wie wir heute über den Inhalt unserer eigenen Festplatten verfügen. Dazu brauchen wir insbesondere Alternativen zu den hürdenreichen und anfälligen APIs, mit denen im zentralisierten Internet heute (manchmal) auf veröffentlichte wissenschaftliche Daten zugegriffen werden kann.

So, wie aus der Perspektive digitaler Archive dezentrale Ansätze dabei helfen können, den Reibungsverlust beim Übergang von privater zu öffentlicher Domäne zu verringern, kann aus der Perspektive der Datennutzer die gleichen Ansätze dabei helfen, bereits veröffentlichte Daten leichter zu benutzen. Diese erhöhte Zugänglichkeit für Jedermann, kombiniert mit einem offenen Markt für modulare Dienste (siehe These 2), könnte sich zudem positiv auf die Landschaft wissenschaftlicher digitaler Dienste auswirken. Es besteht die Hoffnung, dass wir in Zukunft mehr innovative, belastbare und reproduzierbare Dienste auch von weniger privilegierten Player sehen werden; Dienste, die sich für die Akteure in der Wissenschaft als nützlich und inspirierend herausstellen könnten.

Epilog: Dezentrale Anwendungen helfen, Big Data für WissenschaftlerInnen belastbar und vertrauenswürdig zu strukturieren – jetzt sind die etablierten Player der wissenschaftlichen Infrastruktur am Zug

Dieser Blogartikel behandelte das Potenzial von Blockchain und P2P für das Arbeiten mit großen, komplexen, dynamisch wachsenden Objektsammlungen in der Wissenschaft. Dezentrale Anwendungen können dabei helfen, belastbare, vertrauenswürdige Antworten zu geben auf die Herausforderung, Big Data entsprechend den Bedürfnissen von WissenschaftlerInnen zu strukturieren. Für Bibliotheken, aber eben auch für Forschungsförderer, Universitäten, Verlage und andere Player in der wissenschaftlichen Infrastruktur gilt es daher jetzt, das Momentum der Dezentralität aufzunehmen, und die eigenen Rollen und Geschäftsmodelle entsprechend weiterzuentwickeln.

Weitere mögliche Ansätze dafür zeigen unter anderem Sönke Bartling und Benedikt Fecher auf. So könnten die Finanzströme der Forschungsförderung künftig durch Smart Contracts geregelt werden – Programme also, die von einer verteilten, blockchain-basierten Virtuellen Maschine ausgeführt werden. Auch die vielfältige Funktion von Gutachten in der Wissenschaft könnte von der Dezentralisierung profitieren, da es leichter wird, zuverlässige Pseudonyme zu verwenden, und Wissenschaftler/innen dadurch vor ungerechter Begutachtung zu schützen.

Lambert Heller

Head of TIB Open Science Lab // @Lambo at Mastodon and at TIB