Verteilter Speicher: Dokumente an der Blockchain

Die Kombination von Smart Contracts und Distributed File Storage bietet viele Möglichkeiten, Daten kostengünstig, aber dennoch sicher abzulegen und schnell verfügbar zu machen.

In Pocket speichern vorlesen Druckansicht 11 Kommentare lesen
Verteilter Speicher: Dokumente an der Blockchain
Lesezeit: 12 Min.
Von
  • Frank Polster
Inhaltsverzeichnis

Distributed-File-Storage-Anwendungen haben ihren Ursprung in den Peer-to-Peer-Netzwerken (P2P). Der Begriff ist spätestens durch die bekannte Blockchain-Anwendung Bitcoin stärker in den Fokus gerückt. Mit Ethereum und der Implementierung sogenannter Smart Contracts ist es salonfähig geworden.

P2P-Architekturen sind jedoch viel länger etabliert. In der Vergangenheit kamen sie primär für den direkten Datenaustausch zwischen Clients zum Einsatz. Dabei legte Shawn Fanning 1999 mit der Musiktauschbörse Napster den Grundstein. Clients haben sich mit einem Server verbunden und ihre Dateien angeboten oder Daten von anderen Clients abgerufen. Das Prinzip war einfach, aber mit der zentralen Instanz schnell Ziel von Copyright-Klagen der Musikindustrie gegen den Betreiber. Letztlich stellte Napster unter dem Druck der Klagen von Künstlern wie Metallica den Dienst ein.

Doch Napster avancierte zum Vorbild für viele weitere P2P-Filesharing-Dienste, wie Audiogalaxy, Morpheus, Kazaa, edonkey, eMule und schließlich BitTorrent. Deren Popularität hing entscheidend von den Faktoren Nutzerfreundlichkeit, Angebot und Auswahl sowie Datendurchsatz ab.

Die Bedienung von BitTorrent ist etwas komplizierter als beispielsweise bei eMule, weil es sogenannte Torrent-Dateien benötigt. Das Angebot hing primär von den Angeboten der Nutzer im Netzwerk ab: ohne Torrent-Dateien keine Downloads. BitTorrent stach jedoch andere P2P-Filesharing-Dienste mit dem Trumpf des erhöhten Datendurchsatzes.

Mit dem Aufkommen von Blockchain entwickelte sich auch das P2P-Filesharing weiter. Das Projekt InterPlanetary File System (IPFS) hebt das Internet auf eine völlig neue Ebene und bedient sich dabei einer Abwandlung des BitTorrent-Netzwerks. Eine Integration von Git versioniert die Daten.

Der bestechende Vorteil zeigt sich in einem einfachen Szenario: Eine Gruppe eifriger Studierender tippt die Vorlesung gemeinsam in einem Google-Docs-Dokument mit. Bricht nun das Internet der Uni weg, können die Kommilitonen nicht mehr gemeinsam arbeiten, weil der Zugriff zum Google-Server unterbrochen ist; dass sich die Studenten weiterhin im selben Netzwerk befinden, spielt keine Rolle. Wäre Google Docs auf IPFS ausgerollt, könnten die Studierenden gemeinsam weiterarbeiten, da die Anwendung lokal läuft und die Datenhaltung innerhalb des Netzwerks erfolgt.

Die Philosophie eines P2P-Filesharing-Netzwerks ist im Prinzip ein Nehmen und Geben. Das funktioniert auf freiwilliger Basis leider nicht. Das wohl bekannteste Problem für P2P-Filesharing ist Leech and Disappear: Sogenannte "Leecher" (im Deutschen auch "Sauger" genannt) laden Daten aus dem P2P-Netzwerk, sind aber nicht bereit, als Gegenleistung ihre Ressourcen zur Verfügung zu stellen. Das Gegenteil eines "Leecher" ist der "Seeder". Er stellt anderen Benutzern die Dateien auch längerfristig zum Download bereit. Das Leechen stellt eine Gefahr für die Benutzbarkeit von Tauschbörsen dar, führt letztendlich zu einer Zentralisierung und verlangsamt das Netzwerk insgesamt.

Um dem vorzubeugen, bietet beispielsweise das Blockchain-Netzwerk Filecoin dem Nutzer finanzielle Anreize für das Bereitstellen von Inhalten. Filecoin befindet sich eine Ebene über IPFS. "Filecoins" dienen als Währung, um Inhalte zu erwerben und zu verdienen.

Neben IPFS haben sich eine Vielzahl von Projekten entwickelt, die Distributed File Storage und Blockchain-Anwendungen verbinden, etwa das SAFE Network von MaidSafe, StorJ, Sia und Swarm. Sie haben es sich zur Aufgabe gemacht, das Prinzip von IPFS zu erweitern. MaidSafe hat mit dem SAFE Network ein Netzwerk geschaffen, das nicht nur dem Tausch von Dateien, sondern der Bereitstellung ganzer Anwendungen dient.

Sia und StorJ sind sogenannte Consumer-File-Storage-Projekte. Beide Projekte entstanden mit der Motivation, Cloud-Storage abzulösen. Die Software verschlüsselt Kundendaten lokal und legt sie auf verschiedenen Rechnern des Netzwerks in gesicherten Containern ab. Es werden dabei Verträge mit Hostern geschlossen, die zum Teil eine Provision hinterlegen müssen, wenn sie Dateien von Kunden hosten. Die Verträge liegen in einer Blockchain und enthalten Key-Performance-Indikatoren, etwa zur Up-time, Bandbreite und Größe des Speicherplatzes. Eine Übersicht über aktuelle Provider für Distributed File Storage gibt es bei Smith + Crown Analysis.

Letztes Jahr stellten Programmierer auf der Ethereum-Entwicklerkonferenz Devcon2 das Projekt "Swarm" vor, das Pendant von IPFS für Ethereum. Swarm basiert auf dem Netzwerkprotokoll devp2p von Ethereum. Es bietet darüber hinaus beispielsweise eine verschlüsselte Verbindung. Statt einer eigenen Kryptowährung sorgen unterschiedliche auf Ethereum gehostete Verträge für Anreize innerhalb des Netzwerks. Das Anreizsystem besteht aus den drei Teilen: "Swap, Swear & Swindle".

"Swap" steht für Swarm Accounting Protocol und bezeichnet einen Smart Contract in Form eines Scheckbuchs. Es hält fest, wer Daten versendet beziehungsweise empfangen hat. Über diesen Smart Contract lassen sich Schecks ausstellen und einlösen, die einen gewissen Ethereum-Wert repräsentieren. Das soll vor allem die Geschwindigkeit optimieren.

"Swear" ist die zweite Komponente des Anreizsystems von Swarm. Swear ist ebenfalls ein Smart Contract, der ermöglicht, dass Nodes als Langzeitspeicher fungieren, indem sie eine Sicherheitseinzahlung (eng. "Collateral") veranlassen. Anschließend können die Nodes versprechen, dass sie Daten bereitstellen.

Die dritte Komponente "Swindle" steht für "Storage With Insurance Deposit, Litigation and Escrow". Sie regelt im Streitfall, ob der Hoster seine Kaution verliert oder nicht. Daten können auf dem Weg zum Hoster verloren gehen, etwa wenn die Übertragung über einen anderen Node erfolgt. Der Hoster kann seine Unschuld belegen, indem er einen Beweis der Datenaufsicht erbringt. Alternativ kann er beweisen, dass ein anderer für die Speicherung der Daten zuständig ist, was beispielsweise in einer Transaktion auf der Blockchain hinterlegt ist.

Bei der Datenorganisation und bei Anreizsystemen kann die Blockchain-Technik P2P-Filestorage und Filesharing-Netze weiterbringen. Wie das aussehen kann, soll ein kleiner Prototyp zeigen, der die Businesslogik in einen Smart Contract auf Ethereum auslagert und die Datenhaltung in Swarm abwickelt. Das Frontend ist eine Webanwendung.

Viele Entwickler nutzen zum Erstellen von Smart Contracts Testrpc, einen vollumfänglichen Ethereum-Client ohne Ethereum. Da Testrpc kein Swarm unterstützt nutzt der Prototyp stattdessen eine Dockerumgebung, die Ethereum- und Swarm-Clients startet und dadurch ein vollständiges Testnetzwerk bereitstellt. Der Code dazu findet sich auf Github.

Zum Entwickeln der Anwendung kam mit Truffle ein Framework zum Entwickeln und Deployen von Smart Contracts auf Basis von Ethereum zum Einsatz. Neben dem fĂĽr das Beispiel verwendeten Starter auf Basis von Angular 4 existieren viele Startersets fĂĽr React wie beispielsweise React Box.

Der Grundstein der Anwendung liegt darin, eine Verbindung mit dem Ethereum-und dem Swarm-Netzwerk herzustellen. Die Docker-Umgebung stellt auf Port 8545 einen Ethereum RPC (Remote Procedure Call) und auf Port 8500 einen Swarm RPC bereit. AuĂźerdem verwendet das Beispiel die Bibliotheken web3 fĂĽr Ethereum und web3-bzz, um mit den Knoten zu kommunizieren. Die Ethereum Foundation hat Web3 entwickelt, um eine JavaScript Bibliothek fĂĽr Webanwendungen bereitzustellen, die es erlaubt einfach mit Bestandteilen von Ethereum wie Smart Contracts, Filestorage und Kommunikation zu interagieren, .

this.web3 = new Web3('http://localhost:8545');
this.bzz = new Bzz('http://localhost:8500');

Anschließend muss die Anwendung dem Nutzer eine Möglichkeit bereitstellen, eine Datei hochzuladen. Konkret ist dies als einfaches Formular mit einer Dateiauswahl umgesetzt:

<input [(ngModel)]="sendingFile" 
class="input"
type="file"
placeholder="95"
(change)="onChange($event)"
name="sendingFile"
#sendingFileModel="ngModel">
<input [(ngModel)]="fileDescription" 
name="fileDescription"
class="input"
type="text"
placeholder="Whitepaper Secret ICO"
#fileDescriptionModel="ngModel">

Beim Verwenden des Formulars liest die Anwendung die Datei ein und fĂĽgt sie zu Swarm hinzu. AnschlieĂźend wird der zurĂĽckgelieferte Hash-Wert zusammen mit der Beschreibung aus dem Formular an den Smart Contract in der Blockchain ĂĽbergeben.

Der Smart Contract verfügt über drei öffentliche Funktionen: AddDocument, GetDocument und GetDocumentLength. Über erstere lassen sich Dokumente hinzufügen, GetDocument gibt ein Dokument samt Beschreibung zurück, und die letzte Funktion liefert die Anzahl der Dokumente.

Zunächst wird via Truffle die Instanz des in Ethereum deployten Vertrags bereitgestellt:

const documentManagement = 
require('../../build/contracts/DocumentManagement.json');
DocumentManagement = contract(documentManagement);
this.DocumentManagement.deployed().then(instance => {
dm = instance;
})

Das Einlesen der Datei geschieht mit einem Filereader und einem Buffer:

reader.onloadend = () => {
const buf = buffer.Buffer(reader.result) // Convert data into buffer
this.bzz.upload(buf).then((data) => {
return dm.addDocument(data,
this.fileDescription,
{from: this.account});
}).then((result) => {
this.refreshDocuments();
this.setStatus('Transaction completed.');
});
}

// Read Provided File:
reader.readAsArrayBuffer(this.sendingFile);

Die hinzugefĂĽgten Dokumente lassen sich anschlieĂźend ĂĽber die getDocument- und getDocumentLength-Funktionen auslesen und in einer Tabelle anzeigen.

this.DocumentManagement
.deployed()
.then(instance => {
contract = instance;
return contract.getDocumentLength.call(
{from: this.account})
})
.then((length) => {
for (let i = 0; i < length.toNumber(); i++) {
contract.getDocument.call(i,
{from: this.account}).
then(val => {
console.log(val);
this.documents.push({
hash: val[0],
description: val[1]
});
});
}
});

Das Ergebnis kann anschlieĂźend das Frontend beispielsweise in einer Tabelle anzeigen:

<table class="table">
<tr *ngFor="let entry of documents">
<td>{{entry.description}}</td>
<td>
<a href="http://localhost:8500/bzzr:/{{entry.hash}}/">
Download</a>
</td>
</tr>
</table>

Die gesamte Anwendung können Interessierte über GitHub auschecken, testen und modifizieren.

Bei der Kombination von Smart Contracts und Distributed-File-Storage-Lösungen müssen Entwickler auf die Datensicherheit achten. Es ist nahezu unmöglich, Daten aus einem Distributed File Storage selbstständig und vor allem vollständig zu entfernen. Weiter sollte bei den einzelnen Systemen auf Verschlüsselung der Inhalte und der Kommunikation geachtet werden. Letztere ist teilweise verschlüsselt, die Ablage und Bereitstellung jedoch nicht. Bei IPFS ist das beispielsweise nicht der Fall: Das Übertragen und Halten der Daten erfolgt in Klartext. Somit können alle Nutzer eine Datei abrufen, wenn sie den Hash dazu kennen. Weiter können Außenstehende des IPFS Netzwerks durch die nicht vorhandene verschlüsselte Kommunikation einfach mitlauschen.

Über die bereitgestellten Bibliotheken ist es recht einfach, Daten in einem Distributed-File-Storage-System abzulegen. Jedoch sind alle Nutzer dafür verantwortlich, dass ihre Daten redundant auf diverse Nodes verteilt sind, um einen Datenverlust zu vermeiden. Dafür können sie passende Anreizsysteme nutzen. Weiter müssen sie darauf achten, dass der Datenschutz gewahrt ist. Die Beispiel-Implementierung etwa übermittelt die Hashes im Klartext über eine Transaktion an einen Smart Contract. Darüber kann jeder, der an dem Netzwerk teilnimmt, den Hash aus der Transaktion auslesen und die Datei im Swarm aufrufen. Für eine echte Anwendung sollten Entwickler eine Form der Verschlüsselung zur Ablage der Daten verwenden.

Distributed-File-Storage-Anwendungen sind seit geraumer Zeit auf dem Markt. In Kombination mit Blockchain wird es für den verteilten Speicher noch mal richtig spannend: DFS hilft dabei, Dokumente an die Blockchain zu "hängen". Mit Blockchain lassen sich wiederum Anreizsysteme für Distributed File Storage realisieren. Auf der DevCon3 gab es dieses Jahr zudem Anwendungen zu sehen, die zeigten, wie etwa Videostreaming oder eine Node-to-Node Kommunikation über Swarm erfolgen kann.

[Update 13.11. 08:00 Uhr]:Das GrĂĽndungsjahr von Napster und der Name SAFE Network wurden korrigiert.

Frank Polster
beschäftigt sich seit etwa 15 Jahren mit Peer-to-Peer-Systemen und wurde 2012 erstmals auf den Bitcoin aufmerksam. Seit Beendigung seines Masterstudiums der Wirtschaftsinformatik in Göttingen arbeitet er als Software Engineer für den Bereich Distributed Ledger Technologies bei MaibornWolff GmbH.
(rme)