Was ist eine DApp?

Eine dezentrale Anwendung (decentralized application, DApp) ist eine Anwendung, die einen Teil ihrer zentralen Regeln oder ihres Zustands — etwa Guthaben, Eigentum und Freigabeeinträge — einem dezentralen Netzwerk wie einer Blockchain zur Ausführung und Speicherung übergibt. Nutzende bedienen sie meist weiterhin über eine Web- oder Mobiloberfläche, doch die wesentlichen Ergebnisse können von mehreren Beteiligten im Netzwerk nach gemeinsamen Regeln validiert werden, statt nur von einer Datenbank der betreibenden Partei abzuhängen.

„Dezentral“ beschreibt, wie Kontrolle und Abhängigkeiten einer Anwendung verteilt sind; es ist kein automatisch erworbenes Label. Eine DApp kann ihre Kernverträge onchain ausführen und gleichzeitig von einer einzigen Website, einer Datenschnittstelle, einem Administrationsschlüssel oder einem Offchain-Server abhängen. Eine DApp zu beurteilen heißt daher, Schicht für Schicht zu prüfen, woraus sie besteht und wer jede Schicht kontrolliert.

Woraus eine DApp üblicherweise besteht

Eine DApp ist meist kein einzelner Smart Contract, sondern ein Gesamterlebnis, das mehrere Komponenten zusammen bereitstellen:

• Benutzeroberfläche: Web- oder Mobil-App, die Informationen anzeigt und Aktionen annimmt;
• Wallet: hält oder ruft die Signaturfähigkeit der Nutzenden auf, die damit Kontoverbindungen und Transaktionen bestätigen;
• Onchain-Programme: Smart Contracts oder Netzwerkprogramme, die Überträge, Freigaben und Zustandsänderungen nach ihrem Code verarbeiten;
• Netzwerk-Verbindungsdienste: senden Abfragen und signierte Transaktionen an Blockchain-Nodes;
• Offchain-Dienste: können Suche, Indizierung, Benachrichtigungen, Bildspeicherung oder die Lieferung externer Daten übernehmen.

Die DApp-Einführung von Ethereum betrachtet Smart Contracts und eine Frontend-Oberfläche als die verbreitete Kombination. Andere Netzwerke können andere Programm- und Kontenmodelle nutzen. Solana trennt zum Beispiel ausführbare Programme von den Konten, die veränderliche Daten halten. Die Umsetzungen unterscheiden sich, doch Lesende können eine Anwendung mit denselben Fragen prüfen: Oberfläche, Autorisierung, Ausführung im Netzwerk und Datenherkunft.

Die wesentlichen Stationen eines Vorgangs

Nach dem Öffnen einer DApp kann die Oberfläche zunächst öffentliche Informationen lesen — ein Guthaben, eine Kursangabe oder einen bestimmten Onchain-Eintrag — über einen Node oder über einen Indizierungsdienst (einen Indexer), der Onchain-Daten abfragbar aufbereitet. Solche Lesevorgänge ändern den Blockchain-Zustand in der Regel nicht und erfordern keine Signatur für jede Abfrage; was angezeigt wird, hängt dennoch von den Daten des verbundenen Dienstes und vom Abfragezeitpunkt ab.

Startet die nutzende Person einen Vorgang, der den Zustand ändert, erstellt die DApp eine Transaktionsanfrage und übergibt sie der Wallet. Die Wallet sollte Netzwerk, Zieladresse, Gegenstand der Freigabe und möglicherweise anfallende Gebühren anzeigen; nach der Bestätigung signiert sie die Transaktion mit der Signaturfähigkeit des betreffenden Kontos.

Die signierte Transaktion geht anschließend an Blockchain-Nodes. Die Nodes prüfen Signatur und Transaktionsformat nach dem Protokoll und führen das Zielprogramm beim Erstellen oder Validieren eines Kandidatenblocks aus. Sobald die Transaktion in einem gültigen Block enthalten ist, wird das Ausführungsergebnis Teil des Zustands dieser Chain und kann von anderen Nodes nachgerechnet und gelesen werden. Scheitert die Ausführung, sollte sich die Oberfläche ebenfalls nach dem tatsächlichen Transaktionsergebnis aktualisieren und nicht nur anzeigen, dass eine Anfrage gesendet wurde.

In einen gültigen Block aufgenommen zu werden bedeutet nicht zwangsläufig sofortige endgültige Bestätigung. Eine Transaktion kann weitere Bestätigungen benötigen, und unter bestimmten Netzwerkbedingungen kann der Blockverlauf auch reorganisiert werden. Ab wann etwas als endgültig gelten kann, hängt vom Konsensmechanismus des jeweiligen Netzwerks ab.

Dieser Ablauf zeigt, dass die Webseite selbst die Blockchain in der Regel nicht unmittelbar verändert. Die Oberfläche bereitet Anfragen vor und zeigt sie an, die Wallet übernimmt die Autorisierung, und Netzwerk sowie Onchain-Programme bestimmen, ob sich der Zustand regelkonform ändert.

Eine Wallet zu verbinden ist nicht die Freigabe einer Transaktion

Eine Wallet zu verbinden lässt eine DApp meist nur wissen, welche öffentliche Adresse gewählt wurde, und eröffnet ihr einen Kanal, um Anfragen an die Wallet zu senden. Welche Konten die Anwendung sehen und welche Anfragen sie stellen kann, hängt von der Wallet und dem verwendeten Verbindungsstandard ab. Das Verbinden darf nicht der Übergabe eines privaten Schlüssels gleichkommen und bedeutet nicht, dass eine Übertragung von Assets freigegeben wurde.

Nachfolgende Anfragen können unterschiedliche Zwecke haben:

• Eine Nachricht signieren: belegt, dass das Konto einen bestimmten Text oder bestimmte Daten signiert hat, ohne zwangsläufig eine Onchain-Transaktion zu erzeugen;
• Eine Transaktion senden: bittet das Netzwerk, einen Übertrag oder einen Contract-Aufruf auszuführen;
• Token-Freigabe: erlaubt einer Adresse oder einem Programm, Token in einem festgelegten Umfang zu bewegen;
• Netzwerk wechseln: lässt die Wallet zu einer anderen Blockchain oder einem Testnetzwerk wechseln.

Nutzende müssen den tatsächlichen Inhalt jeder Anfrage klar erkennen können. Die Verbindung zu einer Website zu trennen beendet üblicherweise nur die aktuelle Sitzung; bereits onchain eingetragene Token-Freigaben oder andere Rechte werden dadurch nicht automatisch widerrufen.

Onchain-Regeln und Offchain-Oberflächen

Was Onchain-Programme übernehmen, können Netzwerkbeteiligte gemeinsam prüfen, doch die Webseite, die Nutzende sehen, kann weiterhin von einem bestimmten Team gehostet werden. Eine Website kann aktualisiert, abgeschaltet, im Zugang beschränkt werden oder falsche Informationen anzeigen, während ein bereits bereitgestellter Contract fortbestehen kann.

Dass ein Contract weiterhin onchain liegt, heißt nicht, dass gewöhnliche Nutzende ihn bequem weiterverwenden können. Nötig sind außerdem eine funktionierende Oberfläche, die richtige Contract-Adresse, eine Node-Verbindung und die erforderliche Dateninterpretation. Technisch versierte Nutzende können eine andere Oberfläche verwenden oder den Contract direkt aufrufen, das hängt aber davon ab, ob der Contract einen passenden Einstiegspunkt bietet, und erhöht den Aufwand.

Umgekehrt belegt eine Oberfläche mit offenem Quellcode oder verteiltem Hosting nicht, dass das Onchain-Programm keine Administrationsrechte hat. Eine Kontrollstruktur zu beurteilen heißt, Frontend-Veröffentlichung, Upgrade-Rechte der Contracts, Pausenrechte, Rechte über Mittel und externe Abhängigkeiten getrennt zu prüfen.

Nicht alle Daten liegen zwangsläufig onchain

Eine Blockchain eignet sich für Zustände, die gemeinsam validiert werden müssen, doch große Mengen an Bildern, Videos oder Suchdaten direkt dort zu speichern kann teuer sein. DApps halten daher oft Kernguthaben und Rechte onchain und legen weitere Inhalte auf gewöhnliche Server oder verteilte Dateinetzwerke.

Ein Beispiel ist das InterPlanetary File System (IPFS), ein verteiltes Dateiprotokoll, das Daten über ihren Inhalt und nicht über einen festen Serverort auffindet. IPFS erzeugt für Inhalte eine überprüfbare Datenkennung. Das hilft Lesenden zu prüfen, ob der erhaltene Inhalt zur Kennung passt, garantiert aber nicht, dass stets jemand online ist und die Datei bereitstellt, und belegt auch nicht, dass ihr Inhalt zutrifft.

Einen Weblink oder eine Inhaltskennung onchain festzuhalten belegt nur, dass die Anwendung diesen Verweis gespeichert hat. Ob das Ziel erreichbar ist, wer es pflegt, ob es ersetzt werden kann und wie lange es vorgehalten wird, bleibt im konkreten Aufbau zu prüfen.

Der Grad der Dezentralisierung ist schichtweise zu beurteilen

Statt zu fragen, ob eine DApp „vollständig dezentral“ ist, lohnt es sich, jede Schicht zu prüfen:

• Ausführung: Werden die Kernregeln von mehreren Nodes gemeinsam ausgeführt oder von einem einzelnen Server entschieden?
• Zustand: Wo liegen die wesentlichen Guthaben und Rechte, und wer kann sie ändern?
• Upgrades: Lassen sich die Contracts aktualisieren, und wessen Zustimmung erfordert ein Upgrade?
• Oberfläche: Gibt es nur einen offiziellen Einstiegspunkt, und können andere eine Alternative bereitstellen?
• Daten: Hängt die Anwendung von einem einzigen Node-Dienst, Indexer, Oracle oder Dateiserver ab?
• Governance: Wer ist für Pausieren, Parameteranpassung und Mittelverwaltung zuständig?

Unterschiedliche Antworten ergeben unterschiedliche Kontrollstrukturen. Mehrere gemeinsam Signierende zu verlangen, vor dem Wirksamwerden einer Änderung eine Wartezeit vorzusehen oder per öffentlicher Abstimmung zu entscheiden verteilt jeweils einen Teil der Rechte, beseitigt aber nicht automatisch jede konzentrierte Abhängigkeit; ebenso kann das Beibehalten einer Notfallpause eine bewusste Risikoentscheidung sein. Ein Artikel sollte den tatsächlichen Aufbau benennen, statt aus dem Namen „DApp“ zu schließen.

Wie sich eine DApp von einer gewöhnlichen Anwendung unterscheidet

Beide Arten von Anwendung können Webseiten, Konten und Backend-Dienste haben. Der Unterschied liegt vor allem darin, wer die wesentlichen Zustände und Regeln bestätigt.

Bei einer gewöhnlichen Anwendung nehmen üblicherweise die Server der betreibenden Partei Anfragen an, verändern eine Datenbank und bestimmen die Softwareversion. Nutzende müssen darauf vertrauen, dass die betreibende Partei Daten korrekt speichert, und erreichen den Dienst in der Regel nur über die von ihr bereitgestellten Schnittstellen.

Eine DApp kann Teile der Regeln und des Zustands in ein Blockchain-Netzwerk legen, das Nodes nach dem Protokoll ausführen. Nutzende signieren Transaktionen mit eigenen Konten, und andere Oberflächen können dieselben Onchain-Programme aufrufen. Diese Überprüfbarkeit bringt jedoch Abwägungen mit: Gebühren, öffentlicher Zustand, Warten auf Bestätigung, Contract-Fehler und die Abstimmung von Upgrades.

Eine DApp ist daher nicht „eine Anwendung ohne Entwicklungsteam und Server“. Sie verlagert bestimmte Entscheidungen von einem einzelnen Backend in ein gemeinsames Netzwerk und kann dabei Offchain-Komponenten behalten.

DApps, Smart Contracts und Onchain-Organisationen

Ein Smart Contract ist Code, der onchain ausgeführt wird; eine DApp ist die vollständige, nutzerseitige Anwendung und umfasst meist Smart Contracts, eine Oberfläche und weitere Dienste. Ein Contract kann von mehreren DApps genutzt werden, und eine DApp kann mehrere Contracts aufrufen.

Eine dezentrale autonome Organisation (decentralized autonomous organization, DAO) ist eine Organisationsform, die Onchain-Regeln, Abstimmungen oder Rechte mehrerer Parteien nutzt, um Entscheidungen und Ressourcen zu koordinieren. Eine DAO kann eine Abstimmungsoberfläche über eine DApp bereitstellen, doch eine DApp ist nicht zwangsläufig eine DAO und muss keinen Governance-Token ausgeben.

Ebenso macht ein Token eine Anwendung nicht automatisch dezentral. Tokenverteilung, Administrationsrechte, Contract-Upgrades und Kontrolle über die Oberfläche sind weiterhin getrennt zu prüfen.

Wesentliche Grenzen und Risiken

Risiken einer DApp können aus jeder Schicht kommen:

• der Smart-Contract-Code hat Fehler, oder Administrationsrechte gehen über die Erwartungen der Nutzenden hinaus;
• die Oberfläche wird manipuliert und verleitet zum Signieren einer falschen Transaktion;
• die Wallet zeigt nicht klar an, was aufgerufen wird;
• ein Node oder Indizierungsdienst liefert veraltete, falsche oder unvollständige Daten;
• ein Dienst, der externe Informationen onchain einreicht, liefert unzutreffende Daten;
• Dateien, Domainnamen oder der offizielle Einstiegspunkt werden eingestellt;
• das Basisnetzwerk ist überlastet, ändert seine Gebühren oder hat eine Störung.

Dass eine Transaktion auf einer Blockchain erfolgreich ausgeführt wurde, zeigt nur, dass sie den damals geltenden Netzwerk- und Contract-Regeln entsprach. Es belegt nicht, dass die nutzende Person die Anfrage verstanden hat, und auch nicht, dass die von der Anwendung gelieferten Offchain-Informationen zutrafen.

Häufig gestellte Fragen

Muss eine DApp einen eigenen Token haben?

Nein. Ein Token kann für Zahlungen, Rechte oder Governance dienen, ist aber keine notwendige Bedingung dafür, dass etwas eine DApp ist.

Sind alle Daten einer DApp öffentlich?

Nicht zwangsläufig. Transaktionen und Zustand einer öffentlichen Blockchain lassen sich meist lesen, doch eine Anwendung kann zusätzlich Offchain-Datenbanken, verschlüsselte Daten oder Privacy-Techniken nutzen. Was tatsächlich sichtbar ist, hängt von Netzwerk und Entwurf ab.

Lässt sich eine DApp nach Abschaltung der offiziellen Website weiter nutzen?

Die Onchain-Programme können fortbestehen, doch Nutzende brauchen außerdem eine alternative Oberfläche, eine Node-Verbindung und die richtigen Contract-Informationen. Ob die Nutzung weitergehen kann, hängt davon ab, ob jede Komponente offen und verfügbar ist.

Wird bei einer DApp der private Schlüssel an die Website übergeben?

Eine normale Wallet-Interaktion erfordert nicht, einen privaten Schlüssel an eine Website zu geben. Die Wallet signiert innerhalb ihres eigenen Sicherheitsbereichs und übergibt dann die Signatur oder die signierte Transaktion an die Anwendung. Dennoch ist Vorsicht geboten bei Oberflächen, die Seed-Phrase oder privaten Schlüssel verlangen oder zum Signieren gefährlicher Anfragen drängen.

Hat eine DApp zwangsläufig keine Administration?

Nicht zwangsläufig. Ein Contract kann Rechte für Upgrades, Pausieren, Parameteranpassung oder Mittelverwaltung behalten. Prüfe den konkreten Code und die Rechtevergabe statt den Namen der Anwendung.

Verwandte Begriffe

Lies weiter über Smart Contract, Ethereum, die EVM, Non-Custodial-Wallet und Blockchain, oder kehre zum Krypto-Glossar zurück.

Quellen

• Ethereum.org: Einführung in Dapps — grundlegendes Verhältnis zwischen Frontend, Smart Contracts und dezentralem Netzwerk.
• Ethereum.org: Einführung in Smart Contracts — Bereitstellung, Aufrufe und Ausführungsgrenzen von Onchain-Programmen.
• IPFS Docs: how IPFS works — Content-Adressierung, Datenkennungen, Routing und Dateiübertragung.
• Solana Docs: programs — Umsetzungsbeispiel mit Trennung von ausführbaren Programmen und eigenständigen Datenkonten.