Blockchain für das Labor
Vielen ist das Thema Blockchain nicht geheuer und das Gerede über die “Blockchain Revolution” oder “das neue Internet” scheint lediglich ein Mittel, um den Hype um Kryptowährungen zu schüren. Dabei sollte sich die Laborforschung, Pharma, Chemie und Biotech mit dem Thema auseinandersetzen, denn diese Technologie der Dezentralisierung hat gerade in regulierten Bereichen ein enormes Potential.
Ich muss zugeben, bis vor wenigen Monaten hatte ich Null Ahnung von Kryptowährungen und wenig Ahnung von Blockchain Technologie.
Was dann irgendwann 2016 mein Interesse an der Technologie weckte, war die Idee, eine Blockchain für ein dezentralisiertes System zur Speicherung von Laborergebnissen zu verwenden.
Ein Text, der mich im Sommer 2017 dahingehend beeinflusst hat, war der Artikel von Xavier Armand “Why science should embrace decentralized cloud storage”. Xavier behandelt da nämlich eine Herausforderung, mit der Cloud-Software zum Datenmanagement im Wissenschaftsmarkt (wie elektronische Laborjournale) zu kämpfen haben:
Die Angst von Forschern, die eigenen Daten irgendjemandem anderes anzuvertrauen. Ich will hier nicht auf die Sinn- oder Unsinnigkeit dieser Angst eingehen, nur soviel sei gesagt: Die Bedenken sind natürlich irgendwo nachvollziehbar, schlussendlich sind Daten das Kapital eines jeden Forschers.
Aber welche Auswirkungen hat diese Angst auf Innovationen im Markt für wissenschaftliche Software? Ganz einfach: Softwareschmieden müssen Lösungen anbieten, die lokal in der Domäne des Forschers installiert werden können - und das ist teuer. Das Entwickeln und Unterhalten von on-premise Lösungen, das Management von unterschiedlichen Installationen und mehreren Codebases, sowie der zusätzliche Support usw. ist viel kostspieliger als wenn ausschließlich eine Cloud-Software unterhalten werden müsste. Deshalb ist es beispielsweise für ein junges, innovatives Unternehmen in diesem Markt schwerer als in anderen Märkten, günstige Preise anzubieten. Beispiel: Eine Software, die nur als Cloud Lösung angeboten wird (eine Codebase, ein Releaseplan, ein Support…) kostet 10€ pro Nutzer pro Monat. Nun können wichtige, wertvolle Kunden nur gewonnen werden, wenn auch eine on-premise Lösung angeboten wird. Die reine Unterhaltung einer solchen Lösung kann locker eine Preiserhöhung um 50% auf 15€ pro Nutzer pro Monat nötig machen, von langsameren Release-Zyklen sowie dem erheblichen initialen Entwicklungsaufwand ganz zu schweigen. Bei Software, die eigentlich auch die Kollaboration über Organisationsgrenzen hinweg einfacher machen soll, kommt es außerdem zu erheblichen Einschränkungen in der Funktionalität, da der reibungslose Datenaustausch von einer Standalone-Lösung zur anderen Standalone-Lösung nicht so ohne Weiteres stabil zu realisieren ist - zumindest nicht, wenn ein bestimmtes Preisniveau gehalten werden soll.
Diese “unnötig” hohen Preise und Einschränkungen machen es natürlich insbesondere im akademischen Bereich, in dem Budgets knapp sind schwieriger, eine kritische Masse an zahlenden Kunden zu erreichen. Ich glaube persönlich, dass viele gute, innovative Ideen an genau diesem Dilemma scheitern.
Daher treibt eigentlich jeden innovativ denkenden Teilnehmer im Bereich für wissenschaftliche Software die folgende Frage um: Wie kann man dieses on-premise Problem lösen? Was kann Forscher, Pharma- Chemie- und Biotech-Unternehmen sowie große wissenschaftliche Institutionen davon überzeugen, der Cloud zu vertrauen?
Blockchain Technologien könnten eine mögliche Antwort sein: Es gibt schon seit einiger Zeit ambitionierte Blockchain Startups wie Sia, Storj, MaidSafe und Shift, die Cloudspeicherung mittels Blockchain dezentraler, sicherer und sogar günstiger machen wollen. Es gibt Ansätze für völlig neuartige Wege der Datenspeicherung im Netz, wie zum Beispiel das “Interplanetary File System” (IFPS) oder das Swarm Protokoll für die Ethereum Blockchain.
All diese Ansätze haben das Potential, in der in Sachen Datenspeicherung extrem konservativ denkende Forschungswelt zum Umdenken zu bewegen und somit die Tür für schnellere Innovationszyklen bei wissenschaftlicher Software zu ermöglichen.
Dezentralisierter Cloud-Speicherung
Die Geschichte des dezentralen Cloudspeichers beginnt eigentlich mit dem Peer-to-Peer (P2P) Sharing, Napster & Co. Durch diese Wild-West-Zeiten wird natürlich die Wahrnehmung der frühen Internetgeneration geprägt: In der Cloud sind Daten für jeden zugänglich, meistens auf unseriösen Websites.
Ich erwähne das hier, weil sich genau diese Generation jetzt möglicherweise als Entscheidungsträger mit der Weiterentwicklung von P2P Netzwerken im Rahmen von Blockchain Technologie auseinandersetzen muss, möglicherweise in ganz seriösen Bereichen wie eben in der Forschung. Und ich habe die starke Vermutung, dass diese Prägung dabei hemmt, Blockchain Technologien, Kryptowährungen usw. als Lösung für ein seriöses Umfeld ernst zu nehmen.
Dabei hatten P2P Netzwerke im Gegensatz zu den damaligen Hosting-Lösungen, immer schon einen entscheidenden Vorteil: Sie waren viel dezentraler und boten damit eine Redundanz, die anderswo nicht zu finden war. Deshalb war und ist es ja auch so schwierig bzw. unmöglich, diese Netzwerke abzuschalten.
Die Wahrnehmung von P2P Netzwerken als rechtliche Grauzone kommt meiner Ansicht nach daher, dass sich die gute “sharing is caring” Ideologie, aus der diese Netzwerke entstanden sind, irgendwann abnutzt. Bei P2P Netzwerken gibt es irgendwann viele “Leecher” (Sauger), die nur noch runter laden, ohne eine Gegenleistung zu erbringen. Im Vergleich dazu gibt es nur wenig “Seeder”, die Daten hosten und verfügbar halten. Genau das führt dann eigentlich wieder zur Zentralisierung. Hinzu kommt, dass die Seeder, die in einem solchen Umfeld noch mitmachen, nicht mehr von Ideologie getrieben sind, sondern unseriöse Methoden entwickeln, um sich zu finanzieren (Stichworte Spiel-, Gewalt- und Nacktwerbung). Und das prägt dann eben die Wahrnehmung von P2P Netzwerken.
Mittlerweile sind ja auch die großen Hoster wie AWS usw enorm dezentral aufgestellt: Die Daten sind redundant in vielen Datenzentern gespeichert. Aber der entscheidende Unterschied zu P2P liegt darin, was den “Vertrag” zwischen Datenanbieter und Hoster angeht: Es ist nur eine einzige Drittpartei im Spiel ist, der man vertrauen muss, nämlich in diesem Falle Amazon.
Und das ist ja eigentlich, was Forscher fürchten: Ich muss meine Daten, mein wichtigstes Kapital, einer Drittpartei anvertrauen - mit Betonung auf “einer”.
Genau das ist einer der wichtigsten Entwicklungskonzepte der Blockchain-basierten P2P Cloud Speicherung: Es werden Anreize geschaffen, so dass die P2P Hoster für die Speicherung und Verfügbarmachung von fremden Files entlohnt werden, sie bekommen z.B. Bitcoins, Filecoins oder andere Kryptowährungen für das Seeden von fremden Daten. Dadurch soll einer Zentralisierung, wie sie in Napster- und Bittorrent Zeiten entstanden ist, entgegengewirkt werden. Anstatt also 10.000€ im Monat an AWS zu zahlen, könnten auch 1€ pro Monat an 10.000 Seeder-Nodes gezahlt werden und gleichzeitig durch ein dezentrales System eine viel höhere Sicherheit und geringere Abhängigkeit geschaffen werden. Gleichzeitig versprechen die dezentralisierten Cloud-Storage Lösungen auch, dass die auch viel günstiger sind.
Rein technisch geht es dann so, dass Dokumente (auch große Datenmengen) lokal verschlüsselt werden und auf verschiedenen Rechner des P2P Netzwerkes abgelegt werden. Dadurch wird Zugangskontrolle und Sicherheit gewährt.
Die Integrität der Daten wird über durch den Konsensmechanismus der Blockchain gewährt: Die Daten (bzw. deren Hashsums, also die eindeutige, kryptographische Repräsentation der Daten) werden bei jedem Ereignis, dass die Datei betrifft (“Transaktion”) aufs Neue überprüft. Sollte auf einem oder mehreren Nodes (also Teilnehmer des Netzwerks) der Hash nach der Transaktion nicht mehr mit der Mehrheit der Hashs auf den anderen Nodes übereinstimmen, werden die Daten auf diesen Nodes mit den korrekten Daten überschrieben (Konsensusmechanismus). Je nach System können “bösartige” Nodes auch ausgestoßen werden oder müssen eine Strafe zahlen. Anders als in den Wild-West Zeiten von Napster & Co. wird zwischen den Teilnehmern des Netzwerkes also eine Art ein multilateraler, technischer Vertrag geschlossen.
Rekapitulation: Was ist denn jetzt eigentlich unser Anwendungsfall?
Eins müssen wir an dieser Stelle klarstellen: Der initial beschriebene Anwendungsfall (Wie macht man die Nutzung einer Software zum Management von Forschungsdaten in der Cloud attraktiver?) umfasst nicht nur die dezentrale Speicherung von Daten bzw. Dokumenten. Wir wollen ein ganzes Programm, eine Anwendung dezentral speichern und ausführen, die dann mit dezentral gespeicherten Daten arbeitet. Wir befassen uns also eigentlich mit zwei Use Cases, mit “Dezentraler Datenspeicherung” und einer “Dezentralen Anwendung”.
Für die dezentrale Datenspeicherung in der Wissenschaft wollen wir
- große Dokumente im Netz speichern oder zumindest den Zugang zu großen Dateien über das Netz ermöglichen,
- den Zugang zu den Dokumenten genau kontrollieren können,
- Effizient nach Dokumenten suchen, dafür müssen Dokumente strukturiert abgespeichert werden können.
- Dokumente jederzeit und schnell hoch- und runterladen können
Für eine dezentrale Applikation für das Management von Forschungsdaten wollen wir
- Mit dezentral gespeicherten Daten arbeiten, d.h. neue Daten und Dokumente erzeugen und editieren und ggf. auch löschen, wenn die gute wissenschaftliche Praxis oder Regularien nicht verletzt werden
- Nach Daten suchen und Daten aggregieren
- alles bieten, was auch eine zentrale Applikation bietet, eine gute UX, gute Performance usw.
Um ein letztes Mal das Problem zu rekapitulieren: Wir haben diesen Anwendungsfall nur, weil...
- die Wissenschaft, Pharma, Chemie und andere regulierte Bereiche immer noch eine Riesen Angst vor Cloud-Applikationen und Cloud-Speicher haben,
- dadurch die Notwendigkeit von on-premise Lösungen, lokalen, abgeschirmten Installationen usw. besteht, was zu
- Höherer Komplexität und dadurch zu höheren Kosten und langsamerer Innovationsgeschwindigkeit führt.
Meine Hypothese ist, dass man durch neue Blockchain-basierte oder generell dezentralisierte Ansätze diese Angst besiegen, Komplexität vermindern und dadurch Kosten senken sowie die Innovationsgeschwindigkeit erhöhen kann.
Welche Ansätze gibt es, welche Lösungen, welche Startups?
Ich muss zugeben, dass es auch nach intensiver Beschäftigung mit dem Thema ist für mich immer noch ziemlich vage ist, welcher Ansatz wirklich relevant ist und welcher nicht. Viele Ansätze spielen in das Thema mit hinein, sind aber eigentlich als Lösungen für andere Bereiche gedacht. Wie in den Anfangszeiten des Internets fokussieren sich viele Startups auf den Consumer-Bereich und die Frage ist, welche Ideen und Konzepte dann auch für den B2B Bereich herhalten können. Ich vermute, diese vage Situation entsteht dadurch, dass das ganze Thema noch sehr am Anfang steht. Nach ein wenig intensiver Beschäftigung eröffnet sich einem aber ziemlich schnell ein erstaunliches Potential auf und man kommt in der Ideen-Phase vom Hundertsten ins Tausendste.
Meiner festen Überzeugung nach wird da zum einen noch eine Konsolidierung noch stattfinden (müssen). Für den Moment ist aber macht eine unkonsolidierte, breite Vorstellung aller Ansätze Sinn.
In diesem Sinne: welche Ansätze sind mir über den Weg gelaufen?
Sia, Storj, MaidSafe, Shift: Nach meinem Verständnis handelt es sich bei diesen Services um dezentralisierte Alternativen für Cloud-Speicher wie Dropbox, box & Co. Dabei wird der Speicher aber nicht von einer zentralen Organisation bereitgestellt, sondern von vielen Peers in einem Netzwerk. Diese Peers werden anders als in den alten P2P Netzwerken für die Bereitstellung und Verfügbarkeit von Speicherplatz entlohnt, somit soll einer Zentralisierung wie in klassischen P2P Netzwerken entgegengewirkt werden. Die Messung der Leistung der Zuverlässigkeit eines Peers bedient sich kryptographischer Methoden. Diese Ansätze sind aber hauptsächlich für das Speichern von statischen Dokumenten gedacht, können also zur Lösung des Anwendungsfalles 1 dienen, nicht aber zur Umsetzung einer aufwendigen, dezentralen Applikation für das Arbeiten mit dezentralen Dokumenten (Anwendungsfall 2).
IPFS, das Interplanetary File System. Hiermit habe ich mich alleine schon deshalb länger beschäftigt, weil ich den Namen einfach ziemlich cool finde. Und die Idee dahinter ist auch wahnsinnig innovativ, so dass ich nach meinen Recherchen den Namen definitiv nicht als größenwahnsinnig beschreiben würde! Die Hauptidee hinter IPFS ist, dass Dokumente im Netz keine URL - also eine Adresse - mehr haben, die auf den Ablageort auf einem bestimmten Server oder Server-Cluster (z.B. bei AWS) verweist, sondern einen eindeutigen kryptographische Bezeichnung besitzen, einen Hash. Das ist aber mehr als eine bloße Umbenennung: Mit dem Hash bekommt jedes hochgeladene Dokument eine eindeutige ID und wird dann auf verschiedene Peers/Node/“Mini-Hoster” verteilt. Alle diese Dokumente haben die gleiche ID. Beim Aufruf/Verwenden der Datei wird nicht mehr ein bestimmter Hoster referenziert (IP Adresse), sondern geschaut, welcher am nächsten gelegene Mini-Hoster ein Dokument mit der ID hat. Das File ist also nirgendwo spezifisch hinterlegt, aber kommt trotzdem irgendwo her, wenn man es aufruft. Man kann nicht entscheiden, von welchem Node man eine Kopie der Datei bekommt, das Netzwerk entscheidet aufgrund der Nähe zum Hoster, der die entsprechende ID für die Datei aufgelistet hat. Deshalb auch “Interplanetary”, denn die Erschaffer des IPFS dachten sich: Wenn wir zu einer interplanetaren Spezies werden, wird es natürlich enorm wichtig, dasjenige Dokument zu finden, das am nächsten zu einem liegt und nicht einer spezifischen Adresse zu folgen, die möglicherweise zu weit weg liegt, um schnell abgerufen zu werden. Das derzeitige Internet ist in der Hinsicht ziemlich ineffizient, da es mit vielen unnötigen Kopien von Dokumenten arbeitet, die alle unterschiedliche Adressen haben.
Um einer Dezentralisierung entgegenzuwirken, wird sich der gleichen Methodik bedient wie bei Sia & Co.: Jeder kann Speicherplatz zur Verfügung stellen, für die Bereitstellung von Speicherplatz, Verlässlichkeit usw. Gibt es Krypto-Geld, in diesem Falle Filecoin.
Weiterhin beruht der Datenaustausch auf Bittorrent, heißt: Zwischen Nodes werden nicht komplette Dateien, sondern nur kleine Dateiteile ausgetauscht. Damit werden Bottlenecks umgangen, und große Dokumente können extrem effizient behandelt werden.
Ein Nachteil, über den ich gelesen habe, aber nicht im Einzelnen verifiziert habe ist, dass natürlich jeder mit Wissen über den Hash Zugriff auf eine Datei haben kann. Aber hier könne man eine Blockchain dazwischen schalten, die sozusagen als zweite Ebene den Zugriff auf die Hashs kontrolliert, so der Autor des Artikels.
Aber auch bei IPFS geht es nur um den Austausch von Dateien, also unstrukturierten, statischen Dokumenten, an denen nicht mehr gearbeitet wird. Also: Für Anwendungsfall 1, aber (derzeit) nicht für Anwendungsfall 2 relevant.
Swarm. Dieses Protokoll ist eigentlich das Pendant zu IPFS für die Ethereum-Blockchain, mit den gleichen Vor-und Nachteilen. Also ebenfalls Anwendungsfall 1 - relevant.
DaMaHub Data Management Hub ist eine Implementierung von IPFS für die dezentrale Speicherung von Wissenschaftsdaten. Hier scheint sich eine interessante Community zu entwickeln, die schon die British Library als Partner gewonnen hat. Da aber basierend auf IPFS, derzeit nicht relevant für beide Anwendungsfälle.
Arweave ist ein neuer Wettbewerber für die bisherigen dezentralisierten File-Storage Player wie Sia und Storj (“etabliere Playert” kann man ja gar nicht schreiben). Vorteile gegenüber den genannten soll sein, dass nicht die Bereitstellung von Speicherplatz, sondern nur das Zugänglichmachen einer Datei bei Aufruf belohnt wird. Dadurch wird die Speicherung insgesamt günstiger, sodass Arweave keinen Preis pro Monat, sondern einmalige Preise für die permanente Speicherung von Dateien nimmt. Ich nenne Arweave hier gesondert, weil zum einen ein Faktor für die Wissenschaft sehr interessant ist: Arweave kooperiert mit der Charité Berlin, Europas größtem Universitätsklinikum, um mit hilfe des Arwave Protokolls ein neues wissenschaftliches Journal aufzusetzten, dass der Reproduzierbarkeitskrise den Kampf ansagt. Zum werden Konzepte wie Dezentralisierte Kollaboration an Daten sowie Dezentrale Autorenschaft angegangen (und hoffentlich auch umgesetzt). Ich sehe auf jeden Falle eine deutliche Relevanz für unseren Anwendungsfall 1 und gute Ansätze, dass mit dem Konzept für dezentral gemanagte Kollaboration auch Anwendungsfall 2 Beachtung findet.
BigChainDB Hierbei handelt es sich nach eigenen Angaben um eine Datenbank mit Blockchain-Charakteristiken, die dezentrale Kontrolle ermöglicht. Ich bin nicht Computerwissenschaftler genug, um die Möglichkeiten und Einschränkungen abschließend bewerten zu können, aber diesem Artikel hier kann ich entnehmen, dass das Konzept an einem Punkt scheitert, nämlich dass man allen Peers, auf die die Datenbank verteilt wird trauen können muss. Jeder Node hat Schreibrechte, ohne dass es einen Konsensusmechanismus geben kann, der sagt, was richtig und was falsches Schreiben ist. Das ist noch nicht mal ein Fehler der BigChainDB Implementierung, denn so wie ich das im Artikel zitierte CAP Theorem verstehe, ist das dezentrale Arbeiten an Daten in einer Datenbank gar nicht möglich, ohne auf entweder Availability (A, Verfügbarkeit) oder Consistency (C, Konsistenz) zu verzichten. Mit einer sicheren, dezentralen Datenbank würden beide Anwendungsfälle erschlagen, die Frage bleibt aber: “Geht eine dezentrale Datenbank überhaupt?” Und wenn ja: “Wie?” … und wenn das “Wie?” geklärt sein sollte, bleibt für die Bewertung in Bezug auf unsere Anwendungsfälle die Frage “Wann?”.
Cryptowerk: Ein deutsches Startup, dass das Skalierungsproblem von öffentlichen Blockchains wie Ethereum löst, indem es verschlüsselte Daten von Kunden noch einmal komprimiert und dadurch die Anzahl der Transaktionen auf bis zu 600.000 pro Sekunde erhöhen kann. Zum Vergleich: Die Bitcoin Blockchain schafft 7 Tps, Ethereum 15. Wie die von Cryptowerk vorgestellten Use Cases umfasst diese Anwendung also nicht die Behandlung von dynamischen, großen Datenfiles (Anwendungsfall 2), wie es für die Kollaboration auf dezentral gespeicherten Labordaten nötig wäre. Für die reine Speicherung von statischen Daten (Anwendungsfall 1) gibt es genügend andere Lösungen. Ich nenne Cryptowerk hier trotzdem, weil die innovativen Jungunternehmen Essentim und Innome aus dem LabTech Bereich Cryptowerk nutzen, um Daten von Sensoren im Labor nicht nur in eine Software, sondern gleichzeitig auch auf eine Blockchain zu bringen. Damit kann die Messhistorie als auch Sensordaten unveränderlich gespeichert werden (in diesem Falle wird das Bitcoin Netzwerk verwendet). Die Transaktionen beinhalten hier kleine Daten (Sensormessungen), die natürlich statisch bleiben, der Nutzen liegt also hauptsächlich im Nachweis der Datenintegrität. Ich finde das deshalb interessant, weil dieser Ansatz in Richtung Erschaffung eines integrierten Labor-Audit Trails weitergedacht werden kann. Innerhalb eines IoT-basierten, kommunizierenden Laborumfeldes könnte damit eine durchgängige, unveränderliche Historie der Datentransfers zwischen den verschiedenen Teilnehmern (Geräten, Software, Speicher etc.) erzeugt werden.
IOTA Weil ich Cryptowerk genannt habe, nenne ich auch IOTA. IOTA ist eigentlich eine Kryptowährung, die keine traditionellen Blockchain verwendet, sondern ein sogenanntes “Tangle”. Ich erspare mir die Ausführungen über die Technik, durch den Tangle werden aber wie bei Cryptowerk viel mehr Transaktionen pro Sekunde möglich. Daher ist die Kryptowährung auch dafür gedacht, die schnelle Kommunikation und die Bezahlung zwischen Maschinen im Rahmen von IoT zu ermöglichen, z.B. bei der Erfassung und Weiterverarbeitung von Sensordaten. Das Erfolgsversprechen hat Anklang gefunden, mittlerweile kooperieren unter anderem Volkswagen, Bosch und InnoEnergy mit IOTA.
Weil ich schon etwas vom ursprünglichen Anwendungsfall abgewichen will, will ich an dieser Stelle kurz noch den Think Tank “Blockchain for Science” vorstellen. In diesem Artikel fassen die Forscher Sönke Bartling und Benedikt Fecher zusammen, wie Blockchain-basierte Systeme bei der Verteilung von Fördermitteln, der Reproduzierbarkeit von Forschungsergebnissen und der Vergabe von Credits helfen könnten.
Welche Hürden gibt es beim Thema Blockchain für wissenschaftliche Software?
Exakterweise sollte man schreiben: Welche Hürden gibt es für sichere Dezentralität, denn einige der vorgestellten Ansätze bedienen sich ja nicht nur Blockchain-Technologien, sondern von der Blockchain abgeleiteten Technologien.
Das wir über Weiterentwicklungen der klassischen Blockchain-Idee reden, bringt uns eigentlich auch zur größten Hürde: Wie schon kurz erwähnt, die klassische Blockchain - Bitcoin hier als wichtigstes Beispiel - ist langsam. Aber das ist sie qua Design! Die Blockchain-Technologie wurde nicht entwickelt, um schnell zu sein und große Datenblöcke zu handhaben, sondern um super sicher zu sein, ohne eine zentrale Instanz zu benötigen. Für die ursprünglichen Anwendungsfall, nämlich die Transaktion “wer hat wem wieviel Geld geschickt?” war und ist das auch völlig ok. Aber es führt automatisch zu Skalierungsproblemen, wenn man mit der Technologie auf einmal höhere Geschwindigkeiten (z.B. für viele, viele Sensordaten) oder größere Datenblöcke (z.B. dezentrales File-Storing) handhaben will.
Alle Weiterentwicklung oder alternativen Entwicklungen wollen in irgendeiner Weise dieses Skalierungsproblem lösen, um die Technologie der Dezentralität auf andere Bereiche anwenden zu können.
Fazit 1: Große, statische Daten: Ja. Kleine, dynamische Daten: Ja. Große dynamische Daten: (Derzeit) nein.
Hier in aller Kürze mein Fazit: Für Speicherung und Bearbeitung von großen, dynamischen Dokumenten sowie Suchen von verschlüsselten Inhalten in einem Netzwerk gibt es derzeit noch keine wirkliche Alternative, als den großen Hostern wie AWS zu vertrauen. Für ein dynamisches Datenmanagment-Tool wie labfolder heißt das, dass wir noch etwas warten müssen, bis das Verwalten aller Inhalte in einem dezentralen System wirklich ausgereift ist. Aber mein Fazit ist in technischer Hinsicht auf jeden Fall auch, dass wir darauf nicht mehr lange warten müssen.
Für kleine, wenig komplexe Daten funktionieren viele Ansätze auch mit den traditionellen Blockchains, egal ob es sich dabei um statische oder um dynamische Dokumente handelt. Für große, statische Dokumente sind Blockchain-basierte oder verwandte Technologien schon eine echte Alternative.
Was sich für das Laborumfeld auf jeden Fall jetzt schon lohnt weiter zu denken ist das Thema des integrierten, Blockchain-basierten Audit Trails: Jedes Gerät, jede Software, jedes elektronisches Laborjournal und jede Analysesoftware, könnte ein Node in dieser “labchain” sein, mit hilfe derer dann die korrekte Datenübermittlung validiert wird.
Für dezentrale Archivierung abgeschlossener Experimentaldaten mithilfe neuer File Storage Ansätze ist die Blockchain sicher auch interessant. Diese Daten sind von Natur aus statisch und es muss sichergestellt werden, dass sie nachträglich nicht mehr modifiziert werden können. Hier sind die neuen, dezentralen Dokumentenspeicher wie Storj, Arweave und IPFS sicher jetzt schon eine Alternative zur lokalen Datenspeicherung.
Fazit 2: Falsche Wahrnehmung hemmt Sinneswandel
Zu meinem Fazit gehört auch, dass es meiner Ansicht nach noch einen richtigen Sinneswandel geben muss, um das schon vorhandene Potential zu nutzen und trotz der Hürden das Potential zu erkunden, das diese neue Welt des Internets bereithält.
Dieser Sinneswandel ist - etwas scherzhaft ausgedrückt - nicht nur in “low-tech” Bereichen nötig, sondern definitiv auch in high-tech Bereichen wie der Wissenschaft.
Um meine Hypothese zum derzeitigen Empfinden kurz zu illustrieren, hier mal eine Abbildung, wie in der Laborgemeinde derzeit Cloud Storage wahrgenommen wird:
Forscher: Ich will meine Daten nicht an eine Drittpartei geben. Ich will im physikalischen Besitz aller meiner Daten bleiben, es gibt keine vertrauenswürdige Dritt-Partei (z.B. Hosting provider), die besser darauf aufpassen kann als ich oder die IT Abteilung in meiner Organisation.
Hier ist, wie dezentrale Datenspeicherung mit Blockchain oder Blockchain-inspirierten Technologien wahrgenommen werden sollte:
Forscher: Ich gebe vielen Dritten meine sicher verschlüsselten Daten. Diese Dritten sichern sich gegenseitig ab und wenn einer Blödsinn macht, wird das automatisch korrigiert und die schwarzen Schafe werden ausgestoßen oder bekommen eine Strafe. Es gibt keine Partei, die diesen Mechanismus kontrolliert, sondern das System wird von einer “Gutwilligen, autonomen Maschine, die niemals vergisst” beaufsichtigt.
Vielleicht ist das auch der wichtigste Gedankensprung, den alle Menschen machen müssen: Bei Blockchain geht es gar nicht mehr darum, einem Menschen oder einer Gruppe von Menschen zu trauen - es geht darum, einer Maschine bzw. einem Netzwerk von Maschinen zu trauen. Aber wir sind Menschen und kennen ja gar nichts anderes, als Menschen und komplexen Rechtssystemen zu trauen.
Deshalb hier meine Vermutung, wie Blockchain und Dezentralisierung von 99% aller Menschen wahrgenommen wird:
Forscher: Oh Gott, jetzt muss ich ja nicht nur einer Partei vertrauen, sondern vielen! Und wie soll ich denn wissen, dass das alles mit rechten Dingen zugeht - Das sind ja alles Hacker!
Schlusswort
Insbesondere Forscher sind bestimmt nicht zu blöd, um die Materie zu begreifen und ich glaube, dass Initiativen wie “Blockchain for Science”, DaMaHub und Arweave zeigen, dass einige Wissenschaftler oder wissenschaftsnahe Organisationen die Technik begriffen und begonnen haben, das Potential zu nutzen.
Dennoch ist der Großteil der Foschungs- und Laborgemeinde auch so gestrickt, dass nur das ausprobiert und angewandt wird, was zu 100% verstanden worden ist. Das Potential des Verstehens ist gleichzeitig auch der größte Gatekeeper: Was der Forscher nicht versteht, verdammt er.
Also hoffen wir auf mehr Inhalte, die das Thema noch verständlicher machen - ich werde auf jeden Fall weiter darüber schreiben!
Unsortierte Linksammlung
Guter Heise- Artikel aus November 2017 hier: “Verteilter Speicher: Dokumente an der Blockchain” (Deutsch): https://www.heise.de/developer/artikel/Verteilter-Speicher-Dokumente-an-der-Blockchain-3880570.html?seite=all
Super Artikel zu Vor- und Nachteilen von dezentralisiertem File-Storing und dezentralen Apps, Konzeptpapier für bessere Löung, Sep 2017: https://github.com/TiesNetwork/ties-docs/wiki/Where-do-decentralized-applications-store-their-data%3F
Dann auch ein kürzlich (Jun 2018) erschienener Artikel, der sich auch mit der Desillusion mit Sia, Storj & Co. beschäftigt - und auf der anderen Seite Filecoin und IPFS hyped: https://hackernoon.com/a-crypto-traders-diary-week-11-storage-coins-51da93530623
Artikel über Arweave (Jun 2018): https://www.forbes.com/sites/shermanlee/2018/06/08/blockchain-is-critical-to-the-future-of-data-storage-heres-why/#7526096433e9
IPFS Theorie Video (Deutsch, Jan 2018): https://d.tube/v/sempervideo/a0r7uhpf Fun Fact: Das Video wird über DTube bereitgestellt, der ersten “crypto-dezentralisierten Video-Streaming Plattform”, die sich auch IPFS bedient (https://about.d.tube/). Habe das Video einmal aus Berlin aufgerufen - kein Problem. Dann zwei Tage aus der Nähe von Solingen und folgende Nachricht: “The media could not be loaded, either because the server or network failed or because the format is not supported.” - Vielleicht ein Zeichen dafür, dass wir von “Interplanetary” noch etwas entfernt sind.
Super gutes, aber wenig kritisches Video zu IPFS (Okt 2017): https://youtu.be/BA2rHlbB5i0
Post über Kombination von IPFS und Blockchain, sogar mit Beispiel Lab Record / Health Care, Feb 2018: https://medium.com/@mycoralhealth/learn-to-securely-share-files-on-the-blockchain-with-ipfs-219ee47df54c
Über Ethereum Swarm und wozu es verwendet wird (2016): https://ethereum.stackexchange.com/questions/375/what-is-swarm-and-what-is-it-used-for
Arweave Charite cooperation (Mär 2018): https://medium.com/@arweave/arweave-charit%C3%A9-staff-solving-the-reproducibility-crisis-with-the-blockweave-a9c946315d6b
Allgemein - Wo es Sinn macht zu dezentralisieren und wo nicht (Nov 2017): https://medium.com/hummingbird-ventures/blockchain-when-does-decentralization-make-sense-465d05be1a68