dApp entwickeln: was Sie vor der Beauftragung entscheiden sollten

Der Auftrag für eine dApp wird meist als Produkt beschrieben: eine Anwendung, über die Fans Tickets untereinander weiterverkaufen, ein Gemeinschaftsfonds mit Auszahlungsregeln, ein Bonusprogramm, dessen Punkte Kunden tauschen können. Diese Beschreibung sagt, was der Nutzer sieht, aber nicht, welcher Teil des Produkts inSmart Contractsauf einem Blockchain-Netzwerk ausgeführt wird und welcher Teil eine gewöhnliche Webanwendung ist, mit eigenem Server, eigener Datenbank und eigenem Support-Team. Einedezentrale Anwendungverbindet beides: eine Oberfläche, die der Nutzer bedient, und Smart Contracts, die den Zustand speichern und die Regeln anwenden, die für alle Beteiligten gelten.

Die Unterscheidung ist wichtig, weil sich beide Teile nach dem Launch unterschiedlich verhalten. Die Webanwendung wird mit einem neuen Deployment korrigiert; ein bereitgestellter Smart Contract lässt sich nicht bearbeiten, und wer sein Verhalten ändern will, muss das bereits im Design vorgesehen und festgelegt haben, wer diese Befugnis hat. Aus Sicht des Auftraggebers besteht die Entwicklung einer dApp aus drei Entscheidungen: welche Regeln in die Smart Contracts gehören, wer sie ändern darf und wer die Netzwerkgebühren jeder Transaktion zahlt. Der Rest wird wie eine Webanwendung kalkuliert und gebaut, und die Seiten zuBlockchain-Entwicklungund vonBlockchain-MVPbeschreiben, wie wir diesen Teil umsetzen.

Welcher Teil einer dApp in Smart Contracts läuft und welcher eine Webanwendung ist

Smart Contracts speichern, was mehrere Parteien prüfen müssen, ohne von einem Administrator abhängig zu sein: wer Inhaber eines Vermögenswerts ist, welchen Saldo jedes Konto hat, unter welchen Bedingungen Mittel bewegt werden dürfen. Jeder kann diesen Zustand im Netzwerk einsehen und prüfen, ob jede Änderung den Regeln des Smart Contracts gefolgt ist. Alles andere liegt außerhalb: die Oberfläche, Konten mit E-Mail und Passwort, Suchfunktionen, Benachrichtigungen, Kundenservice und personenbezogene Daten. Dieser Teil kann von einem Server des Unternehmens abhängen, ohne dass das Produkt seine zentrale Eigenschaft verliert, solange er nicht zur einzigen maßgeblichen Quelle für etwas wird, das als on-chain überprüfbar dargestellt wird.

Personenbezogene Daten erfordern eine ausdrückliche Entscheidung. Was in ein öffentliches Netzwerk geschrieben wird, ist für jeden sichtbar und lässt sich später nicht löschen, und der Europäische Datenschutzausschuss legt in seinenLeitlinien 02/2025 zu Blockchain-Technologienals allgemeine Regel fest, dass die Speicherung personenbezogener Daten on-chain zu vermeiden ist, wenn sie mit den Datenschutzgrundsätzen kollidiert. In der Praxis bleiben Name, E-Mail-Adresse und Dokumente in Systemen mit Zugriffsrechten, und im Netzwerk wird höchstens ein Hash gespeichert, der für sich genommen niemanden identifiziert.

Welche Regeln on-chain gehören und wer sie ändern darf

Eine Regel gehört in den Smart Contract, wenn ein Beteiligter ein Interesse daran haben könnte, sie zu umgehen, und die anderen prüfen müssen, dass das nicht geschehen ist. Eine Preisobergrenze für den Weiterverkauf, die Aufteilung von Einnahmen auf mehrere Rechteinhaber oder eine Sperrfrist für Mittel erfüllen diese Bedingung. Ein Aktionsrabatt oder der Text einer Begrüßungs-E-Mail erfüllen sie nicht: Sie ändern sich häufig, und niemand verliert etwas, wenn das Unternehmen sie anpasst. Jede Regel, die in den Smart Contract aufgenommen wird, verteuert die Entwicklung und dasAudit, weil Code, der Werte verwahrt, vor dem Launch Zeile für Zeile geprüft wird.

Die zweite Entscheidung betrifft die Frage, wer diese Regeln ändern darf. Ein Smart Contract kann unveränderlich sein, sodass niemand sein Verhalten ändern kann, oderaktualisierbar, über einen Proxy, der auf eine austauschbare Implementierung verweist, oder über Administrationsfunktionen, mit denen sich Transaktionen pausieren oder Parameter anpassen lassen. Die zweite Variante erlaubt es, Fehler zu beheben, verlagert das Vertrauen aber auf denjenigen, der diese Befugnis kontrolliert. Der Auftrag muss festlegen, was geändert werden darf, wer die Änderung autorisiert (ein einzelner Schlüssel, mehrere Signaturen verschiedener Personen, eine Abstimmung) und mit welcher Vorankündigung gegenüber den Nutzern. Diese Festlegung fließt in die öffentliche Dokumentation des Produkts ein.

Wer das Gas für jede Transaktion zahlt

Jede Transaktion, die den Zustand eines Smart Contracts ändert, kostet eine Gebühr in der Währung des Netzwerks, das sogenannteGas. Richtet sich die dApp an Nutzer, die bereits eineWalletmit Guthaben besitzen, können diese die Gebühr selbst zahlen. Richtet sie sich an Kunden, die noch nie Kryptowährungen gekauft haben, schafft die Aufforderung, dies vor der ersten Transaktion nachzuholen, eine Einstiegshürde, die das Produkt bereits im Design lösen muss, genauso wie die Registrierung oder die Zahlungsmethode.

In Ethereum-kompatiblen Netzwerken gibt es zwei standardisierte Wege, über die das Unternehmen diese Gebühren im Namen des Nutzers zahlen kann.ERC-4337, im Status „Final“ und ohne Änderungen am Protokoll, führt programmierbare Konten sowie einen Smart Contract ein, den Paymaster, der die Transaktion anstelle des Absenders bezahlt.EIP-7702, das in Ethereum mit dem UpgradePectra am 7. Mai 2025aktiviert wurde, erlaubt es einer normalen Adresse, an den Code eines Smart Contracts zu delegieren, sodass ein Dritter ihre Transaktionen sponsern oder mehrere Transaktionen zu einer bündeln kann. Jedes kompatible Netzwerk entscheidet selbst, ob und wann es EIP-7702 übernimmt, daher werden Netzwerk und Zahlungsmodell gemeinsam gewählt. Werden Gebühren gesponsert, wird Gas zu Betriebskosten, die das Unternehmen pro Transaktion einplant und gegen Missbrauch absichert, etwa indem es begrenzt, wie viele Transaktionen es pro verifiziertem Konto bezahlt.

Ein Beispiel: Weiterverkauf von Festivaltickets mit Preisobergrenze

Das Beispiel ist hypothetisch. Ein Festivalveranstalter möchte seine Tickets als Token ausgeben, die Besucher untereinander zu höchstens 110 % des ursprünglichen Preises weiterverkaufen können, und an jedem Weiterverkauf mit 5 % beteiligt werden. Bisher findet der Weiterverkauf auf fremden Plattformen zu Preisen statt, die er nicht kontrolliert. Er möchte Spekulation begrenzen, ohne Besuchern, die nicht teilnehmen können, die Möglichkeit zu nehmen, ihr Geld zurückzubekommen.

Die erste Entscheidung betrifft den Inhalt des Smart Contracts. Preisobergrenze und Weiterverkaufsgebühr gehören hinein, denn genau diese Regeln würde ein Wiederverkäufer umgehen wollen: Lägen sie nur in der Webanwendung, genügte es, den Token außerhalb davon zu übertragen. Damit sie sich nicht umgehen lassen, lässt der Smart Contract nur Übertragungen über seinen eigenen Weiterverkaufsmechanismus zu, eine Form derÜbertragungsbeschränkung. Name, E-Mail-Adresse und Rechnung des Besuchers bleiben außerhalb des Netzwerks in den Systemen des Veranstalters.

Die zweite Entscheidung betrifft die Frage, was der Veranstalter ändern darf. Wird das Festival abgesagt, muss jemand die Tickets stornieren und die Erstattungen auslösen können, also braucht der Smart Contract eine Administrationsbefugnis. Der Veranstalter legt fest, dass zwei von drei Signaturen verschiedener Personen sie ausüben, dass sie nur zur Absage der Veranstaltung dient und dass sie Preisobergrenze und Gebühr nach Verkaufsstart nicht ändern kann. Diese Einschränkung wird programmiert, auditiert und in den Kaufbedingungen veröffentlicht, sodass der Besucher weiß, was der Veranstalter ändern kann und was nicht.

Die dritte Entscheidung betrifft die Frage, wer zahlt. Die Besucher kaufen per Karte und müssen keine Kryptowährungen besitzen. Der Veranstalter sponsert daher die Gebühren für Registrierung, Kauf und Weiterverkauf, mit einer Obergrenze an Transaktionen pro verifiziertem Konto, und plant sie zusammen mit den Kosten des gewählten Netzwerks in seinem Betriebsbudget ein.

Das Beispiel zeigt auch, was der Smart Contract nicht löst. Die Einlasskontrolle bleibt ein physischer Vorgang, bei dem der Token mit der Person abgeglichen wird, und nichts hindert jemanden daran, außerhalb der Anwendung den Zugang zu dem Konto zu verkaufen, auf dem sein Ticket liegt. Die dApp setzt die Preisobergrenze bei jeder erfassten Übertragung durch; den informellen Markt beseitigt sie nicht, macht ihn aber für Käufer auf diesem Weg umständlicher und riskanter.

Eine dApp zu entwickeln heißt festzulegen, was sich später nicht mehr ändern lässt

Das Beispiel zeigt, wo die eigentliche Arbeit liegt. Oberfläche, Konten und Kartenzahlungen sind bekannte Web- und Mobile-Entwicklung mit den üblichen Zeitplänen und Risiken. Was eine dApp ausmacht, ist ein kleiner Kern von Regeln, auf deren eigenmächtige Änderung das Unternehmen verzichtet, und dieser Verzicht verleiht dem Produkt bei seinen Nutzern Glaubwürdigkeit: Die Preisobergrenze gilt, weil der Veranstalter selbst sie nicht mitten im Verkauf anheben kann. Je weniger Regeln in diesen Kern aufgenommen werden, desto günstiger ist das Audit und desto geringer der Schaden eines Fehlers.

Was eine dApp nicht leistet, ist ebenso konkret. Sie ersetzt nicht das Vertrauen in das Unternehmen für alles, was off-chain geschieht, vom Kundenservice bis zur physischen Veranstaltung, und sie macht ein Produkt nicht dezentral, dessen Smart Contract ein einzelner Schlüssel ohne Vorankündigung ändern kann. Enthält der Auftrag keine Regel, die ein Beteiligter umgehen wollen könnte, spricht das dafür, dass das Produkt keine Smart Contracts braucht und als herkömmliche Webanwendung mit einer vom Unternehmen verwalteten Datenbank besser funktioniert.

Was das Angebot enthalten sollte und wer die dApp danach betreibt

Sind diese drei Entscheidungen schriftlich festgehalten, lassen sich Angebote vergleichen. Jedes sollte getrennt ausweisen: die Entwicklung der Smart Contracts, deren externes Audit, die Web- oder Mobile-App, die Integration von Zahlungen und Identität sowie die Betriebskosten, zu denen gesponserte Transaktionsgebühren, der Anbieter für den Netzwerkzugang (RPC-Node) und das Monitoring gehören. Das Audit deckt eine bestimmte Version des Codes ab, und der Artikel zurZertifizierung von Smart Contractserläutert, wie Sie prüfen, ob genau diese Version bereitgestellt wird.

Nach dem Launch muss jemand die Admin-Schlüssel verwahren, die Smart Contracts überwachen, Anfragen und Störungen der Nutzer bearbeiten und die Integrationen pflegen, wenn sich Wallets oder Netzwerk ändern. Bei Metlabs entwickeln wir vollständige dApps, von den Smart Contracts über die Anwendung bis zu ihrem Betrieb, und dokumentieren von Anfang an, was sich ändern lässt und wer das kontrolliert. Der Leitfaden zuBeispiele für dAppsanalysiert Komponente für Komponente, wie bereits laufende Anwendungen diese Entscheidungen gelöst haben.