Decentralized Apps

Paradigmenwechsel oder alter Wein in neuen Schläuchen?

Verteilte Systeme dominieren seit Jahrzehnten die Software-Welt. Während es Anfang der Neunzigerjahre noch Client-/Server-Applikationen waren, wurden um die Jahrtausendwende Web-Anwendungen immer beliebter. Es entstanden auch andere Paradigmen, die sich jedoch nicht durchgesetzt haben und inzwischen in Vergessenheit geraten sind. Eines von ihnen war das der Ultra-Light-Clients mit der Idee, die Applikation komplett auf einem zentralen Server auszuführen und lediglich die darzustellenden Bildschirmänderungen und Interaktionen wie etwa Mausbewegungen und Tastatureingaben zwischen diesem Server und den Geräten der User zu übertragen.

In Web-Applikationen wird die Benutzerschnittstelle auf einem zentralen Web-Server gehostet, von dort auf das Gerät des Users heruntergeladen und im Web-Browser ausgeführt. Der Web-Server befindet sich genauso wie die Business-Logik und die Datenhaltung im eigenen Rechenzentrum des Anbieters der Web-Applikation oder ausgelagert in der Cloud. Im letzteren Fall kann man zwar im geografischen Sinne nicht mehr von „zentral“ sprechen, die zentrale Governance bleibt jedoch weiterhin bestehen: Der Anbieter hat die alleinige Hoheit über die Daten und den Code.

Eine neue Art von verteilten Systemen – Blockchains – ermöglicht die Demokratisierung der Governance. Dazu wird auch der Betrieb der ansonsten zentralen Komponenten der Datenhaltung und Businesslogik dezentralisiert: Jeder User hat eine eigene Kopie der Daten (State) und führt die durch Requests (Transaktionen) ausgelösten Berechnungen (Smart Contracts) lokal auf seinem Gerät (Node) aus. Der verteilte Consensus sorgt dafür, dass die Transaktionen auf allen Nodes des Netzwerks in der gleichen Reihenfolge ausgeführt werden und den State im Gleichtakt verändern. Die Blockchain, Peer-to-Peer-Messaging-Systeme und dezentralisierte Dateisysteme bilden die Bausteine eines neuen Paradigmas: dezentralisierte Applikationen, sogenannte DApps.

Ethereum ^[1] – von einem seiner Mitgründer als „World Computer“ benannt – ist die wohl bekannteste Plattform für DApps. Das Netzwerk besteht aus Nodes, die eine als Client bezeichnete Software (z. B. Geth ^[2] oder Parity ^[3] ) benötigen, um Teil des Netzwerks zu werden und mit anderen Clients zu kommunizieren. Der Client empfängt Transaktionen der User, leitet sie an andere Clients weiter und speichert die Transaktionshistorie sowie den aktuellen State in einer lokalen Datenstruktur, der eigentlichen Blockchain. Manche Clients, die sogenannten Validatoren, spielen eine besondere Rolle im Consensus zur Bestimmung der Reihenfolge von Transaktionen. Sie bündeln Transaktionen in einer von ihnen gewählten Reihenfolge in Blöcke und schlagen diese den anderen Clients vor. Welcher vorgeschlagene Block akzeptiert wird, entscheidet der Consensus-Algorithmus der Clients. Die Clients prüfen die Blöcke, die sie erhalten, und leiten sie an die Clients weiter, mit denen sie in Verbindung stehen. Wird ein Block akzeptiert, werden alle in ihm enthaltenen Transaktionen der Reihe nach ausgeführt. Eine Transaktion kann das Ether-Guthaben (Ether ist die native Kryptowährung in Ethereum) der Senderadresse reduzieren und das Guthaben der Empfängeradresse um eben diesen Betrag erhöhen. Eine Transaktion kann auch einen Smart Contract erzeugen oder eine Methode eines bestehenden Smart Contracts aufrufen. Ein Smart Contract ist ein Objekt mit einer eigenen Adresse, einem Ether-Guthaben sowie Attributen und Methoden wie in jeder objektorientierten Programmiersprache. Die durch Transaktionen aufgerufenen Methoden eines Smart Contracts werden durch die Clients lokal in der Ethereum Virtual Machine (EVM) ausgeführt und die Attribute des Smart Contracts lokal aktualisiert. Smart Contracts können miteinander interagieren, sind von der Außenwelt jedoch vollkommen abgeschottet. Der einzige Weg, ihnen etwas mitzuteilen, ist, über Transaktionen ihre Methoden aufzurufen. Im Zuge der Ausführung können Methoden eines Smart Contracts sogenannte Events emittieren, die im lokalen Event-Log des Clients festgehalten werden, damit externe Applikationen, die mit der jeweiligen Node in Verbindung stehen, auf sie reagieren können.

 Als Benutzerschnittstelle bezeichnen wir in unserem Kontext die Komponenten der Web-Anwendung, die im Browser auf dem Gerät des Users ausgeführt werden. In modernen Web-Anwendungen sind es in der Regel Single Page Applications (SPAs) mit einer einzigen Webpage, die andere von ihr benötigte Komponenten im Hintergrund nachlädt.

SPAs werden grundsätzlich als statische Dateien in einem zentralen Storage, z. B. S3 von Amazon Web Services (AWS), gehostet und zwecks Performance in einem Content Delivery Network (CDN) wie z. B. Cloudfront den Usern zur Verfügung gestellt. Der Server, auf dem die Dateien zum Download bereitstehen, wird mithilfe des Domain Name Service (DNS) aufgelöst. Nach dem Herunterladen wird die SPA lokal im Browser ausgeführt.

SPAs werden in einem dezentralisierten Dateispeicher wie Swarm ^[4] oder IPFS ^[5] (Inter Planetary File System) abgelegt und sind dort über ihren Hashwert auffindbar. IPFS ist ein Netzwerk von Nodes, ähnlich wie Ethereum. Dateien können über einen beliebigen IPFS-Node angefordert werden. Zur Erleichterung der Adressierbarkeit können in einem dezentralisierten Naming Service wie ENS ^[6] (Ethereum Name Service) den Hashwerten auch sprechende Namen zugeordnet werden. Bei ENS handelt es sich um einen Ethereum Smart Contract, der mithilfe von Browsererweiterungen wie Metamask ^[7] über einen Ethereum-Node angesprochen werden kann. Der Browser fragt also zuerst den ENS Smart Contract nach dem Hashwert einer SPA und anschließend IPFS nach der Datei zu diesem Hashwert. Die von IPFS heruntergeladene SPA wird dann lokal im Browser ausgeführt.

Als Business-Logik bezeichnen wir die Funktionalität einer Web-Anwendung, die im Gegensatz zur Benutzerschnittstelle nicht im Browser auf dem Gerät des Users ausgeführt wird. Stattdessen wird auf Anfrage der Benutzerschnittstelle eine Berechnung auf einem zentralen Server angestoßen.

Die Anfragen werden meist von einem in der Cloud laufenden API Gateway (z. B. AWS AppSync) validiert, transformiert, autorisiert und an andere Komponenten zur Verarbeitung weitergegeben. Die anderen Komponenten können z. B. in der Cloud deployte Serverless-Funktionen sein. Diese bei AWS als Lambdas bezeichneten Funktionen werden von der weitergeleiteten Anfrage aufgeweckt und nach Beendigung der Ausführung wieder in einen Schlafmodus versetzt. Der Vorteil hierbei besteht darin, dass bei steigender Last mehrere Kopien einer (stateless) Funktion gestartet werden können, womit eine automatische Skalierung stattfindet und der Cloud-Provider nur die tatsächliche Ausführungsdauer der Funktion verrechnet. Lambdas können während der Ausführung mit anderen Cloud-Ressourcen, Services oder Lambda-Funktionen interagieren. Die Ergebnisse der Ausführung werden vom API Gateway transformiert und der Benutzerschnittstelle zurückgegeben.

Die im Browser mit installiertem Web3 Plugin (z. B. Metamask) laufende SPA nutzt ein Web3-Javascript-Objekt, um sich mit einem Ethereum-Node zu verbinden, der auf demselben Gerät wie dem Browser des Users oder auch auf einem anderen Gerät laufen kann. Über das standardisierte RPC-Interface von Web3 kann die SPA Transaktionen ins Netzwerk senden, über Events im Zuge der Ausführung von Smart Contracts benachrichtigt werden oder Attribute von Smart Contracts abfragen. In einer DApp gibt es keine zentrale Komponente für die Business-Logik wie z. B. die Lambdas in cloud-native Applikationen. Die durch Transaktionen der User ausgelösten Berechnungen und Datenänderungen werden hier in Smart Contracts lokal auf jedem Ethereum-Node durchgeführt, sobald die Transaktion dort im Rahmen eines gültigen Blocks eintrifft.

Unter Datenhaltung verstehen wir die persistenten Daten – strukturiert, semi-strukturiert oder unstrukturiert – einer Web-Anwendung.

Die Business-Logik (z. B. Lambdas) kann auf relationale Datenbanken oder auf NoSQL Datenbanken (z. B. DynamoDB), die in der Cloud laufen, zugreifen. Der Entwickler muss sich hierbei nicht mehr um Skalierung, Replikation etc. kümmern – diese werden automatisch durchgeführt und verrechnet.

Das logische Modell der Datenhaltung von Ethereum ist objektorientiert: Die Attribute eines jeden Smart Contracts werden auf jedem Ethereum-Node persistiert. Das physische Modell ist in einem NoSQL Key-Value Store wie z. B. levelDB oder rocksDB gespeichert. Größere Daten bzw. Dateien werden eher in IPFS oder anderen dezentralisierten Speichersystemen abgelegt.

Nach dem Vergleich der Aufbaustruktur von DApps mit cloud-native Applikationen wenden wir uns nun ihren Eigenschaften zu. Wir betrachten vier Perspektiven – Anbieter, Entwickler, Betrieb und Benutzer – und weisen auf ausgewählte Besonderheiten von DApps hin.

Bei DApps ist die Rolle des Anbieters – gewöhnlich die ursprünglichen Entwickler der DApp – deutlich geschwächt, da die User oft Token-Besitzer und Miteigentümer der Anwendung sind, die als Open-Source-Software ohnehin kollektiv weiterentwickelt wird. Auch die Aufgabe des Betreibers ist dezentralisiert und auf viele kleine Node-Betreiber verteilt. Die Blockchain und verwandte Technologien eliminieren damit „Single Points of Failure“, eine Gefahr, die im Grunde jede zentrale Komponente darstellt. Unter Failure wird hier nicht nur der bloße Ausfall (Crash) einer Komponente verstanden, sondern auch beliebiges bösartiges Verhalten, z. B. Manipulation des Codes oder der Daten von innen (durch den Anbieter) oder von außen (durch einen Angreifer).

Als Beispiel für eine dezentralisierte Governance kann an dieser Stelle das Golem-Projekt ^[8] genannt werden. Hier wurde der zentrale Cloud-Anbieter eliminiert. Die „Cloud“, in der Auftragsberechnungen (z. B. Rendering von Bildern) ausgeführt werden, ist ein Netzwerk von Usern, die ihre freien CPU- bzw. GPU-Kapazitäten bereitstellen und dafür belohnt werden. Sie müssen sich gegenseitig nicht kennen oder vertrauen, die entsprechende DApp und die darunterliegende Blockchain sorgen dafür, dass alles korrekt abläuft und abgerechnet wird. 

Die Entwicklung von DApps unterscheidet sich grundsätzlich nicht übermäßig von der Entwicklung von cloud-native Anwendungen. Es ist jedoch zu beachten, dass einmal deployter Code im Nachhinein nicht einfach gepatched werden kann und die durch Transaktionen ausgelösten Änderungen am State nicht durch einen Administrator korrigiert werden können, wie das bei herkömmlicher Software der Fall ist. Da es in DApps oft um den Transfer von Kryptowährungen geht, können durch fehlerhaften Code ermöglichte Angriffe verheerende Folgen haben. Das prominenteste Beispiel hierfür ist der sogenannte DAO-Hack aus dem Jahr 2016: Hier konnten Angreifer Ether im Wert von etwa 53 Millionen US-Dollar erbeuten. Dies hatte eine Aufspaltung (Hard Fork) des Netzwerks in Ethereum und Ethereum Classic zur Folge, im Grunde bedingt durch einen Softwarefehler des DApp-Entwicklers.

Es zeigen sich jedoch auch Parallelen bei der Softwareentwicklung von DApps und cloud-native Applikationen in Bezug auf Code-Effizienz und die daraus resultierenden Kosten: Bei Smart Contracts müssen Transaktionen mittels sogenannter Gas-Kosten bezahlt werden. Vereinfacht kann man sagen, je länger die Berechnungen im Smart Contract dauern, desto teurer wird es für den User. Auch Lambda-Funktionen in cloud-native Applikationen werden quasi on Demand bezahlt, in diesem Fall jedoch vom Anbieter der App und nicht vom User. In beiden Paradigmen hat aus Entwicklersicht daher die Code-Effizienz direkte Auswirkungen auf die entstehenden Kosten.

Cloud-native Applikationen punkten vor allem mit minimalem Konfigurationsaufwand und automatischer Skalierung aller eingesetzten Komponenten. Limitierungen entstehen, wenn überhaupt hauptsächlich aus Kostengründen. Konträr ist der limitierende Faktor bei Blockchains meist die zugrundeliegende Technologie selbst. So sind Public Blockchains wie Ethereum sehr langsam (< 20 Transaktionen pro Sekunde) und in derzeitiger Form kaum für schreibintensive Applikationen geeignet. Private Blockchains haben zwar einen deutlich höheren Durchsatz, kommen aber nur mit einer begrenzten Anzahl an Validator-Nodes zurecht, was die Dezentralisierung der Governance stark einschränkt. Neben dem Durchsatz ist auch die Größe der Blockchain, die auf jedem Node gespeichert wird, eine Limitierung. Die Datenmenge, die ein sogenannter Archive Node in Ethereum speichern muss, liegt inzwischen im Terabyte-Bereich. Dies mag für Unternehmen als Node-Betreiber keine Hürden darstellen, für Privatpersonen aber sehr wohl, was die Dezentralisierung im Netzwerk erschwert. Der Energieverbrauch der Validatoren (Miner) von Ethereum kann an dieser Stelle nicht unerwähnt bleiben. Diese für die Sicherheit des Netzwerks notwendige Konsequenz des Proof of Work Consensus soll durch die Einführung von Proof of Stake in den kommenden Jahren entfallen.

Beim Arbeiten mit DApps gibt es für die User einen oft unterschätzten Unterschied: vollständige Eigenverantwortung. User müssen sich in erster Linie um ihre Zugangsdaten kümmern, die im Gegensatz zu cloud-native Applikationen nicht beim Betreiber gespeichert sind. Für den Zugang zu einem Account benötigt man einen Private Key, aus dem ein Public Key und die Adresse des Accounts abgeleitet werden. Für die Verwaltung von Private Keys werden sogenannte Wallets genutzt, die sowohl die Erzeugung und Speicherung von Keys, als auch das Signieren von Transaktionen mithilfe dieser Keys gewährleisten. Es gibt verschiedene Arten von Wallets. Bei Online Wallets werden die verschlüsselten Keys noch beim Anbieter und nicht beim User gespeichert. Bei Mobile Wallets liegen sie auf dem mobilen Gerät (Smartphone) des Users, bei Hardware Wallets auf einem externen USB-Gerät, von dem sie nicht herausgelesen werden können, und bei Paper Wallets auf einem nicht-digitalen Medium (Papierblatt). Der Verlust des Wallets hat für den User schwerwiegende Folgen: Er kann auf den Account nicht mehr zugreifen. Da wir von dezentralisierten Applikationen sprechen, gibt es auch niemanden, an den er sich wenden kann, um seine Zugangsdaten zurücksetzen zu lassen. Der einzige Weg zum Wiedererlangen der Keys ist mithilfe der beim Anlegen des Wallets generierten Mnemonics. Es ist eine Kombination von englischen Wörtern, die in der richtigen Reihenfolge zur Ableitung des sogenannten Seeds eines Wallet dienen, aus dem alle Private Keys wiederhergestellt werden können. Diese Mnemonics sollten gut geschützt offline aufbewahrt werden. Benutzer, die heutzutage Social Logins, z. B. ihres Facebook-Accounts, als Zugangsdaten zu einer großen Anzahl von Online-Diensten nutzen und den Komfort der Souveränität bevorzugen, könnten mit der Eigenverantwortung im Umgang mit der Sicherheit ihrer Zugangsdaten überfordert sein und die Benutzerfreundlichkeit von dezentralisierten Apps daher als suboptimal empfinden.

Wir haben die Unterschiede im Aufbau von cloud-native und dezentralisierten Applikationen sowie ausgewählte Eigenschaften aus Sicht verschiedener Rollen betrachtet. Die Daseinsberechtigung beider Paradigmen ist in ihrer Ideologie begründet. Will man eine App als alleiniger Eigentümer betreiben, bietet die Cloud zahlreiche Vorteile. Strebt man gemeinsam mit anderen nach Shared Ownership, können DApps die Antwort auf viele Fragen rund um Vertrauen und Governance bereitstellen.

 

Noch Fragen?

Wie können Sie Chancen und mögliche Einsatzfelder von Blockchain-Lösungen  identifizieren und diese in Ihrer Organisation umsetzen? Erfahren Sie, wie wir Sie beim Thema Blockchain unterstützen können:

 

[1] www.ethereum.org

[2] geth.ethereum.org/docs/

[3] www.parity.io

[4] swarm-guide.readthedocs.io/en/latest/introduction.html

[5] docs.ipfs.io

[6] docs.ens.domains

[7] metamask.github.io/metamask-docs/

[8] golem.network

 

Dr. Zoltan Fazekas & Charly Gomez - arbeiteten zusammen im Blockchain Lab von iteratec und berieten Kunden bei ihren Projekten im Umfeld von Blockchain- und Distributed-Ledger-Technologien. Wir schätzen ihren Beitrag und informieren, dass sie nicht mehr bei iteratec tätig sind.