Technische Sicht

Die Basics

Das Ocean Protocol verfügt über alle notwendigen Funktionalitäten, um einen dezentralen Datenraum aufzubauen. Es ist allein jedoch noch nicht vollständig Gaia-X Kompatibel, da die Vorgaben des Trustframeworks nicht implementiert sind. Es kann aber entsprechend erweistert werden (siehe Pontus-X). [1]

Ocean ist ein dezentrales, Etherium-kompatibles Datenaustausch-Protokoll, und verfolgt eine Multi-Chain Strategie (das bedeutet: die Smart Contracts die die Funktionen des Ocean Protocols implementieren, laufen auf mehreren Blockchains) [3]. Das Protokoll ist damit eine Art Schnittstelle, die es möglich macht eine zugrundeliegende Blockchain zum Teilen von Daten zu nutzen, indem Datensätze mit Token verknüpft werden.

Die sensiblen Daten selbst verbleiben dabei off-chain, auf den Servern und in den Datenbanken ihrer Besitzer, nur der Zugang zu ihnen wird on-chain verwaltet. Dazu wird zu jedem Datensatz, wenn er von seinem Besitzer in Ocean registriert wird, ein Non-Fungible-Token (NFT, nach ERC721) erschaffen, welches die Besitzrechte an den Daten kapselt.

Der Zugang zu den Daten wird über sogenannte Data-Token (fungible Token, ERC20) gehandelt, deren Konditionen der NFT-Inhaber genau festlegen kann. [2, Kapitel 3.3]

Die Architektur

Das Ocean Protocol besteht im Kern aus Smart Contracts, die die Erschaffung der Token regeln.

Zum Zugriff auf diese Smart Contracts gibt es zwei Bibliotheken, ocean.js (Javascript) und ocean.py (Python). Diese unterstützen auch bei der Umsetzung des tatsächlichen Datentransfers, wenn ein Data-Token eingelöst wird.

Daneben gibt es sogenannte Ocean Nodes, die mehrere Funktionen gleichzeitig übernehmen. Sie dienen als Metadaten-Cache, dort können Angebote registriert und gesucht werden, und sie sind verantwortlich dafür, den Zugang zu den bei ihnen registrierten Datensätzen zu kontrollieren. Sie können außerdem Rechenumgebungen für die spezielle Compute-to-Data (C2D) Funktion anbieten, dazu später mehr. [4]

Darauf können dann eigene dApps aufbauen und User Interfaces zur Verfügung stellen, wie zum Beispiel die Marketplaces in . Selbstverständlich benötigt jeder Nutzer eine Wallet zur Verwaltung der Token, dafür hat sich Metamask (https://metamask.io/) als Browser-Extension für Firefox und Chrome etabiliert.

Datentransaktionen

In einem Datenraum sollen Daten übertragen werden können. Wie sieht also der Prozess einer solchen Datentransaktion aus? Betrachten wir ein Beispiel von Alice und Bob.

Alice möchte einen Datensatz über einen auf dem Ocean Protocol basierenden Datenraum vertreiben. Sie nutzt ein User-Interface um auf die NFT-Factory zuzugreifen, und ein Token zu ihrem Datensatz zu erstellen.

Um anderen Nutzern (zum Beispiel Bob) Zugang zu den Daten zu gewähren, muss sie als nächstes Data-Token nach ihren Vorstellungen erstellen. Dabei legt sie detailliert fest, welche Nutzungsrechte für den Käufer eines Datatoken gelten sollen, und zu welchem Preis. Sie kann präzise auswählen welche im Datenraum veröffentlichten Algorithmen für die Verarbeitung der Daten freigegeben sein sollen, und ob die Daten offen verfügbar sind, oder nur einzelnen, handverlesenen Nutzern angeboten werden.

Dieses Angebot registriert sie bei einem Ocean Node ihrer Wahl. Dabei gibt sie ihm die unverschlüsselte URL zu ihrem Datensatz. Der Node verschlüsselt diese, und speichert sie zusammen mit einigen Metadaten als sogenannte DDO in der Blockchain. Wenn Alice keinem Node-Anbieter so weit vertraut, dass sie ihm die URL zu ihren Daten mitteilen möchte, bleibt ihr die Option selbst einen solchen Node zu betreiben. Dies ist zwar mit einem höheren Aufwand verbunden, bringt ihr jedoch zusätzliche Sicherheit. (Infos zum Betreiben eines eigenen Nodes sowie der Node-API findet ihr hier in GitHub)

Erst jetzt kann Alices Angebot von Bob gefunden werden. Dazu durchsucht dieser (bzw. die von ihm genutzte dApp) die Metadaten-Caches aller Nodes des Netzwerks, welche ihm die Metadaten über die bei ihnen registrierten Datensätze zur Verfügung stellen müssen, nach passenden Angeboten.

Mit dem Erwerb eines der Datatoken erhält Bob eine Sublizenz zu Alice' Daten. Schickt er dieses mit einer Anfrage zu den Daten an den Node, bei dem Alice ihr Angebot eingestellt hat, prüft der Node die mit dem Token verbundenen Zugangsrechte, und entschlüsselt die URL zu Alice Daten für Bob. Der Node fungiert hier also als Türsteher zu den bei ihm registrierten Datensätzen.

Compute-to-Data

Compute-to-Data ist eine spezielle Funktion, die es bisher nur im Ocean-Protocol gibt. Sie wird alternativ auch als Algorithmustransakion (vgl. Datentransaktion) bezeichnet.

Die Idee ist, dass sensible Daten nie den Server ihres Besitzers verlassen, oder zumindest nie vollständig in die Obhut des Käufers übergeben werden (durch einfachen Download), sondern die datenverarbeitenden Algorithmen zu den Daten kommen.

Dazu gibt es zwei Möglichkeiten:

• Der Anbieter der Daten stellt selbst eine Rechenumgebung (C2D Environment) für solche Algorithmen zur Verfügung

• Der Betreiber des Ocean-Nodes, bei dem das Daten-Angebot registriert wurde, stellt eine solche Rechenumgebung bereit, und kann entsprechende Nutzungsgebühren erheben

Die Rechenumgebung ist im Kern ein Kubernetes-Cluster, die Algortihmen werden zusammen mit den Daten in einen Pod geladen, können dort in einer geschlossenen Umgebung rechnen, und die Ergebnisse werden anschließend dem Auftraggeber zur Verfügung gestellt.

Das bietet dem Datenbesitzer zusätzliche Sicherheit: er muss seine Daten nie ganz aus der Hand geben, und kann genau auswählen welche C2D-Algorithmen auf seinen Daten zugelassen sind.

Ablauf einer Algorithmus-Transaktion

In einem ersten Schritt müssen sowohl der Datensatz, als auch der Algorithmus in Ocean registriert, und dabei jeweils ein NFT erzeugt werden. Dabei muss der Datensatz für C2D freigegeben, und der spezifische Algorithmus auf eine Whitelist gesetzt werden.

Zu den Metadaten, die bei der Anmeldung des C2D-Algorithmus angegeben werden müssen, gehört ein passendes Docker-Image, welches alle Abhängigkeiten, die benötigt werden beinhaltet, ebenso einen Entrypoint für die Ausführung. Für jeden Algorithmus wird eine Checksumme erstellt, mit der vor der Ausführung überprüft werden kann, dass er nicht manipuliert und korrekt geladen wurde.

Auch für den Algorithmus muss angegeben werden, ob er in “fremde” C2D-Umgebungen geladen werden darf, oder nur auf dem Ocean Node ausgeführt werden darf, bei dem er registriert wurde. Im letzteren Fall bedeutet das, dass der Algorithmus nur auf Daten angewendet werden kann, die beim gleichen Node veröffentlicht wurden. Das kann zum Beispiel dann relevant sein, wenn ein Nutzer Daten und passende datenverarbeitende Algorithmen anbietet und den Node selbst betreibt, damit alles lokal und sicher auf seinem eigenen Server bleibt.

Ein Nutzer, der einen C2D-Algorithmus nutzen möchte, wählt diesen, zusammen mit einem Datensatz und einer freigegebenen Ausführungsumgebung aus, bezahlt für alles, dann startet der Ocean Node den Vorgang.

Ein Operator Service beauftragt eine Operator Engine, einen Pod im Kubernetes-Cluster zu erstellen, alle nötigen Abhängigkeiten und Daten zu laden, und den Prozess zu starten.

Der Algorithmus kann zur Laufzei über das Filesystem im Pod auf die Daten und Metadaten zugreifen, und seine Ergebnisse ebenfalls in einer Datei speichern. Diese wird nach Ende des Berechnungen in einer Cloud gespeichert, der Auftraggeber des C2D-Prozesses bekommt die URL zu den Ergebnissen zurück. Dort liegt neben den Ergebnis-Files auch ein Logfile.

Die Operator Engine ist dafür verantwortlich, nach dem Ende des Prozesses, oder dem Ablauf eines vom Algorithmus-Besitzers angegebenen Zeitlimits, alle Ressourcen wieder freizugeben und die Daten aus dem Cluster zu löschen. [5]

Genauere Infos zu C2D sowie die Spezifikation der API finden sich im Ocean Git-Repository.

Quellen

1. Paper "Ocean Protocol Use-Case Gaia-X: a federated European Data Infrastructure" von DeltaDao

2. Ocean Whitepaper "Tools for the web3 Data Economy" Ocean Protocol Foundation, September 2022

3. Ocean Dokumentation auf deren Website, Kapitel "Networks"

4. Architektur des Ocean Protocols, Version 08/2024, Doku des Ocean Protocols

5. Schema des Ablaufs einer C2D-Anwendung, Doku des Ocean Protocols