Vergleichskriterium: Wo wird der State gespeichert und wo werden die Regeln ausgeführt
«On-chain games vs Web2 games» — ein Architekturvergleich von On-chain-Spielen und Web2-Spielen: wo Regeln ausgeführt werden und wo der Spiel-State (Fortschritt, Inventar, Charakterparameter) gespeichert wird.
Der zentrale Unterschied zwischen «Spielen mit NFTs» und fully on-chain besteht darin, dass im einen Fall der Token on-chain sein kann, während Fortschritt und Regeln serverseitig bleiben.
- Web2 → Gegenstände und Fortschritt sind Einträge in der Entwicklerdatenbank; der Zugriff wird durch Account und Service-Regeln bestimmt.
- On-chain → ein Teil der Logik und/oder des Zustands wird in der Blockchain fixiert; Assets können NFT sein, Handlungen sind Transaktionen.
- Web3-Hybrid → ein NFT kann im Wallet gespeichert sein, aber Gameplay und Fortschritt werden meist auf dem Server aktualisiert.
- Fully on-chain → Regeln und State liegen in Smart Contracts; Client-Anwendungen können sich ändern, während Ausführungsregeln und der Contract-State (Events und Contract-Einträge) im Netzwerk bestehen bleiben.
Zentrale Schlussfolgerung: Wenn Web2-Server abgeschaltet werden, enden Zugriff und Fortschritt in der Regel. Im Web3-Hybrid bleibt das NFT oft im Wallet erhalten, aber die spielbezogene Utility verschwindet, wenn Nutzungsregeln und Fortschritt serverseitig waren.
Die «Quelle der Wahrheit» — die Schicht, die Rechte an einem Asset und den finalen State festhält: Server/Studio-DB oder Smart Contract und Netzwerkdaten.
Aktualisierung: Definitionen von Web3-Hybrid und fully on-chain präzisiert, Kriterien zur Prüfung der «Quelle der Wahrheit» ergänzt und Folgen des Szenarios «server off» hinzugefügt.
Fazit in 4 Punkten: Web2, Hybrid und fully on-chain
Vergleichskriterien: wo der Fortschritt (State) gespeichert wird und wer die Regeln validiert (Server oder Smart Contract).
- Entscheidend ist nicht das Vorhandensein eines NFTs, sondern der Ort der Fortschrittsspeicherung und die Schicht der Regelausführung.
- Web2 → der Server ist die einzige Quelle der Wahrheit und ein Single Point of Failure.
- Web3-Hybrid → der Token kann im Wallet erhalten bleiben, aber die Nutzungsregeln werden oft vom Server vorgegeben.
- Fully on-chain → Regeln und State liegen in Contracts, der Client ist eine Schnittstelle zu den Netzwerkdaten.
Modellvergleich: Assets, Fortschritt, Serverabhängigkeit
Vergleich nach Schichten: Quelle der Wahrheit, Assets, Fortschritt, Serverabhängigkeit und Folgen einer Abschaltung des Dienstes.
| Parameter | Web2 | Web3-Hybrid (teilweise on-chain) |
Fully on-chain |
|---|---|---|---|
| Quelle der Wahrheit | Server/Studio-DB | Server + Blockchain für einen Teil der Rechte/Assets | Smart Contracts und Netzwerkdaten |
| Assets | In-Game-Eintrag | NFT/Token im Wallet; Utility wird häufig vom Server bestimmt | NFT/Token + Nutzungsregeln im Contract |
| Fortschritt (State) | Serverseitig | Meist serverseitig | On-chain (Contract-State) |
| «Server abgeschaltet» | Zugriff und Fortschritt enden meist | NFT kann bleiben, aber Modi/Regeln/Fortschritt können verschwinden | Regeln und State bleiben im Netzwerk, die Oberfläche kann wechseln |
| UX/Geschwindigkeit | Maximal | Mittel (Wallet, Signaturen) | Kompromiss (Fees, Latenz, Zugriffs-Infrastruktur) |
| Hauptrisiken | Zentralisierung: das Studio kann Regeln und Zugriff ändern | Token existiert, aber Utility hängt von Servern ab | Contract-Sicherheit + Skalierung und UX |
Begriffe zum Mitlesen: NFT, on-chain/off-chain, Smart Contract, State
Das minimale Set zum Vergleichen: was ein Asset ist, wo der State gespeichert wird und wo Regeln ausgeführt werden.
- NFT — ein einzigartiger Token in der Blockchain, der den Besitz eines digitalen Objekts bestätigt (z. B. eines Items).
- Smart Contract — Code in der Blockchain, der Regeln ausführt und Daten speichert/aktualisiert.
- On-chain — Aktion oder Daten werden im Blockchain-Netzwerk fixiert.
- Off-chain — Aktion oder Daten werden außerhalb der Blockchain gespeichert (Server, Client, geschlossene DB).
- Fully on-chain — Logik und Zustand des Spiels liegen in der Blockchain; der Client ist eine Oberfläche für Contract-Daten und -Regeln.
- Quelle der Wahrheit — die Schicht, die den finalen Zustand bestimmt: wer ein Asset besitzt, welches Level vorliegt, welches Inventar vorhanden ist.
Modellgrenzen: Web2-Spiel, Web3-Hybrid, fully on-chain
Trennung nach Ausführungskriterium: «tokenisierte Assets» und «Regeln und State in Contracts» sind unterschiedliche Modelle.
Web2-Spiele: der Zustand (Fortschritt, Inventar, Charakterparameter) wird auf zentralisierten Servern gespeichert und aktualisiert.
On-chain-Spiele: Aktionen und/oder Zustand werden in der Blockchain fixiert, Regeln werden durch Smart Contracts ausgeführt.
Web3-Hybrid: Assets werden tokenisiert (NFT/Token), aber ein wesentlicher Teil von Logik und Fortschritt bleibt off-chain.
Fully on-chain: die Blockchain dient als Ausführungsschicht: Logik und State liegen in Contracts, Interfaces können unterschiedlich sein.
Das Vorhandensein eines NFTs garantiert keine dauerhafte Utility. Utility bleibt nur erhalten, wenn Nutzungsregeln und/oder kritischer State in Contracts verankert sind oder ein kompatibler Client existiert, der den Contract-State liest und dieselben Regeln ausführt.
Rechte an Assets: «in der DB» vs «im Wallet»
Token-Besitz und vorhandene Spiel-Utility sind unterschiedliche Zustände, weil sie durch unterschiedliche Schichten bestimmt werden.
Web2: Asset als Eintrag im System des Entwicklers
Ein Item existiert als Zeile in der Datenbank, Zugriff ist das Recht eines Accounts, Service-Funktionen zu nutzen.
- Account und Plattformregeln bestimmen, welche Items und Modi verfügbar sind.
- Account-Sperren oder die Schließung des Dienstes beenden in der Regel den Zugriff auf Items und Fortschritt.
- Übertragung und Handel sind häufig durch Produktregeln und Studio-Infrastruktur eingeschränkt.
Konsequenz: Das Asset bleibt ein Datenbankeintrag und kein unabhängiges Objekt außerhalb des Dienstes.
Web3: Asset als Token (NFT/Token) auf einer Wallet-Adresse
Der Inhaber kontrolliert den Token über Schlüssel, aber die Utility wird dadurch bestimmt, wo die Regeln zur Token-Nutzung ausgeführt werden.
- Der Token kann unabhängig vom Spiel-Account erhalten bleiben, weil der Eintrag im Netzwerk liegt.
- Wenn Nutzungsregeln serverseitig definiert sind, kann ein Studio die Utility abschalten, ohne den Token selbst zu verändern.
- Nach einer Service-Schließung kann der Token-Preis fallen, wenn keine kompatiblen Clients oder on-chain Nutzungsregeln existieren.
Konsequenz: Der Token kann auf der Adresse bleiben, aber die «Spiel-Utility» verschwindet, wenn serverseitige Regeln und Fortschritt abgeschaltet werden.
Abgrenzung: «NFT im Wallet» bedeutet Token-Besitz. «Token gewährt Spielrechte» hängt von der Schicht ab, in der Nutzungsregeln beschrieben und ausgeführt werden.
Kernidee: Ein NFT kann bestehen bleiben, auch wenn die Utility nicht mehr vom Server bedient wird.
Fortschritt und Prüfungen: serverseitiger State vs Contract-State
Die Kernfrage: wo der State aktualisiert wird und welche Schicht Zustandsübergänge bestätigt — Server oder Smart Contract.
Serverseitiger State: der Fortschritt wird in der Service-DB gespeichert, die «offizielle Version» wird vom Server definiert.
Contract-State: der Fortschritt wird in Smart-Contract-Daten und Netzwerk-Events fixiert, Übergänge werden durch Contract-Logik geprüft.
| Verglichen wird | Serverseitiger State | Contract-State |
|---|---|---|
| Wo Fortschritt gespeichert wird | Service-Datenbank | Contract-Daten + Netzwerk-Events |
| Wer Übergänge bestätigt | Serverlogik und Service-Regeln | Smart-Contract-Logik (was erlaubt und was verboten ist) |
| Wer die finale Version festlegt | Server als einziger Schiedsrichter | Netzwerk und Contract als Quelle der Wahrheit |
| Admin-Änderungen | Möglich (z. B. Rückabwicklung einer Reward-Ausgabe) | Durch Contract-Regeln und Transaktionen begrenzt |
| Wie Ergebnisse bestätigt werden | Über Service- und Account-Daten | Über Netzwerkdaten (Contract-State und Events) |
| Wenn der Dienst abgeschaltet wird | Fortschritt und «offizielle Version» können mit der DB verschwinden | State und Events bleiben im Netzwerk, die Oberfläche kann wechseln |
Beispiel: Wenn ein Saisonergebnis (Rating und Reward) on-chain gespeichert ist, lässt es sich über Netzwerkdaten auch bei einem Client-Wechsel bestätigen; wenn es serverseitig gespeichert ist, verschwindet die «offizielle Version» bei einer Service-Abschaltung.
Kompromiss: on-chain Rechte und on-chain Ergebnisse, off-chain Gameplay
- On-chain: Besitz, seltene Rewards und Saisonergebnisse (was unabhängig vom Server nachweisbar sein muss).
- Off-chain: hochfrequente Aktionen (Kampf, Bewegung, Matchmaking) für Geschwindigkeit und UX.
- Konsequenz: on-chain verankert seltene, aber bedeutende Ereignisse, nicht jede Gameplay-Aktion.
Je mehr Rechte und finale Ergebnisse in Contracts gespeichert sind, desto geringer ist die Serverabhängigkeit für die Bestätigung von Besitz und Saisonresultaten.
Abschalt-Szenario: Was in jedem Modell verloren geht
Das Abschalten von Servern wirkt sich je nach Modell unterschiedlich auf Assets und Fortschritt aus, weil sich die Quelle der Wahrheit unterscheidet.
Web2: Das Abschalten der Infrastruktur beendet die Aktualisierung des serverseitigen State und die Datenbereitstellung für den Account.
Konsequenz: Zugriff auf Fortschritt und Items endet meist mit dem Dienst.
Web3-Hybrid: Das NFT bleibt als Netzwerk-Eintrag auf der Adresse, aber serverseitige Elemente (Fortschritt, Modi, Regeln zur Nutzung) können verschwinden.
Konsequenz: Der Token existiert, aber die Utility endet, wenn Server abgeschaltet werden.
Fully on-chain: Logik und State liegen in Contracts, daher bleiben Daten im Netzwerk unabhängig von einer einzelnen Firma erhalten.
Einschränkung: Der bequeme Zugriff hängt von Client-Apps und der Infrastruktur zum Lesen von Daten (RPC und Indexer) ab.
On-chain Grenzen: Fees, Latenz, UX und Contract-Risiko
On-chain erhöht die Prüfbarkeit, bringt aber Fees, Latenz und Anforderungen an das Key-Management mit sich.
- Durchsatz und Latenz: das Schreiben von Aktionen erfordert Transaktionen und Bestätigungen.
- Kosten von Operationen: das Speichern und Aktualisieren von State on-chain kann teuer sein.
- UX-Hürden: Wallet, Keys, Signaturen und Wiederherstellung — eine zusätzliche Risikoschicht.
- Zugriffs-Infrastruktur: RPC, Indexer und Interfaces beeinflussen Komfort und Verfügbarkeit beim Lesen des State.
- Contract-Sicherheit: Codefehler und falsche Berechtigungen führen zu irreversiblen Folgen für State und Assets.
Konsequenz fürs Game-Design: Häufige Mikroaktionen werden selten on-chain verlagert; on-chain fixiert eher seltene, aber bedeutende Ereignisse (Rechte, Rewards, Saisonergebnisse).
Warum Hybride populär sind: die Blockchain wird für Rechte und ökonomische Ereignisse genutzt, hochfrequentes Gameplay bleibt off-chain, um Fees und Latenz bei jeder Aktion zu vermeiden.
Zentraler Kompromiss: on-chain Prüfbarkeit wird mit Fees und Reibung in der UX bezahlt.
Auswahlkriterien: Wann on-chain Wert stiftet — und wann nicht
Architektur-Filter: wo Rechte an Assets und überprüfbare Ergebnisse wichtig sind — und wo Geschwindigkeit und nahtlose UX wichtiger sind.
On-chain ist häufiger sinnvoll
Wenn der Wert an Besitz, Herkunft und Sekundärmarkt gebunden ist.
- Sammel-Items und Karten, bei denen der Sekundärmarkt wichtig ist.
- Ressourcenökonomien und Crafting mit Regeln, die über Netzwerk-Events überprüfbar sind.
- Langlebige Welten, in denen Rechte an Assets und Saisonergebnisse erhalten bleiben müssen.
Web2 ist häufiger rationaler
Wenn Geschwindigkeit, minimale Reibung und keine Fees pro Aktion wichtiger sind.
- Real-time Genres (Shooter, Action), bei denen Latenz kritisch ist.
- Casual Games mit Massen-Onboarding ohne Wallets und Signaturen.
- Projekte, in denen Items außerhalb des Dienstes keinen Wert haben.
Beispiele (Orientierung an Ansätzen)
Keine Empfehlung und keine Qualitätsbewertung. Ziel ist zu zeigen, wie der Markt unterschiedliche Architekturen üblicherweise bezeichnet.
Prüfung nach Kriterien: (1) Wird Fortschritt im Account oder im Contract gespeichert? (2) Gibt es einen alternativen Client/State-View ohne die offizielle Website? (3) Wird die NFT-Utility durch den Contract oder durch serverseitige Regeln definiert?
- Tokenisierte Assets (oft Hybrid) → Items und Charaktere als NFTs, Gameplay und Fortschritt sind off-chain.
- Ökonomische und Sammler-Formate → verankern häufiger on-chain Rechte an Assets und Marktregeln rund um Assets.
- Fully on-chain Richtungen → versuchen, Regeln und State in Contracts zu halten, der Client dient als Interface zu Netzwerkdaten.
Prüfkriterium: Wichtiger als NFTs ist der Ort der Fortschrittsspeicherung und die Schicht der Regelausführung.
Drei häufige Wahrnehmungsfehler
Erwartungsfehler entstehen meist, weil «Token-Besitz» mit «funktionierender Utility» und der «Quelle der Wahrheit» vermischt wird.
«Es gibt ein NFT — also kann das Spiel nicht geschlossen werden»
Der Token kann im Netzwerk existieren, während serverseitiges Gameplay und serverseitiger Fortschritt verschwinden können.
- Token-Besitz verpflichtet den Dienst nicht, Spielregeln weiter zu unterstützen.
- Das Risiko hängt vom Ort der Fortschrittsspeicherung und vom Ort der Ausführung der Regeln zur Token-Nutzung ab.
Konsequenz: die Prüfung sollte mit Fortschritt und Regeln beginnen — nicht mit dem Vorhandensein eines NFTs.
«On-chain = vollständig dezentral»
On-chain kann punktuell genutzt werden: für Assets, aber nicht für Fortschritt und Match-Regeln.
- On-chain Assets bedeuten nicht on-chain Fortschritt.
- Ein hybrides Modell kann kritische Server-Abhängigkeiten behalten.
Konsequenz: die «Quelle der Wahrheit» für Fortschritt und Regeln liegt auf dem Server oder im Contract.
«Fully on-chain hat keine Einschränkungen»
Der Contract-State bleibt im Netzwerk, aber Fees, Latenz und Zugriff über die Lese-Infrastruktur beeinflussen die UX.
- Fees und Bestätigungen begrenzen die Frequenz von on-chain Aktionen.
- Verfügbarkeit von Clients, RPC und Indexern beeinflusst den Komfort beim Lesen des State.
Konsequenz: relevant sind die Anzahl on-chain Aktionen und die Verfügbarkeit des State-Views ohne ein einziges Frontend.
FAQ
Was ist on-chain gaming?
Was ist der Unterschied zwischen Web2- und Web3-Spielen — einfach erklärt?
Was passiert mit einem NFT, wenn das Spiel schließt?
Ist es möglich, Web3-Spiele ohne Wallet zu spielen?
Lässt sich Fortschritt ohne Server erhalten?
Warum gibt es noch wenige fully on-chain Spiele?
Abschließender Check: on-chain vs Web2 anhand von drei Merkmalen
Die Modellbewertung reduziert sich auf eine Frage: wo die «Quelle der Wahrheit» für Fortschritt und Regeln liegt.
- Fortschritt: Saisonergebnis und zentrale Rewards werden im Contract gespeichert oder bleiben in der Service-DB.
- Regeln: State-Übergänge werden durch den Smart Contract oder durch serverseitige Logik bestätigt.
- Abschalt-Risiko: Wenn der Dienst verschwindet, bleiben nur Netzwerkdaten und ein kompatibler Zugang dazu erhalten.
Wenn Fortschritt und Regeln auf dem Server leben, bleiben on-chain Elemente Assets — aber sie bewahren nicht die «offizielle Version» des Spiels.