Kryterium porównania: gdzie przechowywany jest state i gdzie wykonywane są reguły
„On-chain games vs Web2 games” — porównanie architektury gier on-chain i gier Web2: gdzie wykonywane są reguły oraz gdzie przechowywany jest state gry (postęp, ekwipunek, parametry postaci).
Kluczowa różnica między „grami z NFT” a fully on-chain polega na tym, że w jednym przypadku token może być on-chain, a postęp i reguły pozostają na serwerze.
- Web2 → przedmioty i postęp — wpisy w bazie danych dewelopera; dostęp określają konto i zasady usługi.
- On-chain → część logiki i/lub stanu jest utrwalana w blockchainie; aktywa mogą być NFT, a działania — transakcjami.
- Hybryda Web3 → NFT może być przechowywany w portfelu, ale rozgrywka i postęp zwykle są aktualizowane na serwerze.
- Fully on-chain → reguły i state znajdują się w smart kontraktach; aplikacje klienckie mogą się zmieniać, a reguły wykonania i kontraktowy state (zdarzenia i wpisy kontraktu) pozostają w sieci.
Kluczowy wniosek: po wyłączeniu serwerów w Web2 dostęp i postęp zwykle przestają istnieć. W hybrydzie Web3 NFT często pozostaje w portfelu, ale użyteczność w grze znika, jeśli reguły użycia i postęp były serwerowe.
„Źródło prawdy” — warstwa, która przechowuje prawa do aktywa i końcowy state: serwer/baza danych studia albo smart kontrakt i dane sieci.
Aktualizacja: doprecyzowano definicje hybrydy Web3 i fully on-chain, dodano kryteria weryfikacji „źródła prawdy” oraz konsekwencje scenariusza „server off”.
Wniosek w 4 punktach: Web2, hybryda i fully on-chain
Kryteria porównania: gdzie przechowywany jest postęp (state) i kto waliduje reguły (serwer czy smart kontrakt).
- Nie liczy się obecność NFT, lecz miejsce przechowywania postępu i warstwa wykonywania reguł.
- Web2 → serwer — jedyne źródło prawdy i jedyny punkt awarii.
- Hybryda Web3 → token może pozostać w portfelu, ale reguły użycia często narzuca serwer.
- Fully on-chain → reguły i state w kontraktach, klient — interfejs do danych sieci.
Porównanie modeli: aktywa, postęp, zależność od serwera
Porównanie warstwowe: źródło prawdy, aktywa, postęp, zależność od serwerów i konsekwencje wyłączenia usługi.
| Parametr | Web2 | Hybryda Web3 (częściowo on-chain) |
Fully on-chain |
|---|---|---|---|
| Źródło prawdy | Serwer/baza danych studia | Serwer + blockchain dla części praw/aktywów | Smart kontrakty i dane sieci |
| Aktywa | Wpis wewnątrz gry | NFT/tokeny w portfelu; użyteczność często określa serwer | NFT/tokeny + reguły użycia w kontrakcie |
| Postęp (state) | Serwerowy | Zwykle serwerowy | On-chain (kontraktowy state) |
| „Serwer wyłączony” | Dostęp i postęp zwykle przestają działać | NFT może pozostać, ale tryby/reguły/postęp mogą zniknąć | Reguły i state pozostają w sieci, interfejs może się zmienić |
| UX/szybkość | Maksymalne | Średnie (portfel, podpisy) | Kompromis (opłaty, opóźnienia, infrastruktura dostępu) |
| Główne ryzyka | Centralizacja: studio może zmieniać reguły i dostęp | Token istnieje, ale użyteczność zależy od serwerów | Bezpieczeństwo kontraktów + skalowanie i UX |
Terminy do lektury: NFT, on-chain/off-chain, smart kontrakt, state
Minimalny zestaw pojęć do porównania: co jest aktywem, gdzie przechowywany jest state i gdzie wykonywane są reguły.
- NFT — unikalny token w blockchainie, potwierdzający własność cyfrowego obiektu (np. przedmiotu).
- Smart kontrakt — kod w blockchainie, który wykonuje reguły oraz przechowuje/aktualizuje dane.
- On-chain — działanie lub dane są utrwalane w sieci blockchaina.
- Off-chain — działanie lub dane są przechowywane poza blockchainem (serwer, klient, zamknięta baza danych).
- Fully on-chain — logika i stan gry znajdują się w blockchainie; klient jest interfejsem do danych i reguł kontraktu.
- Źródło prawdy — warstwa, która określa stan końcowy: kto posiada aktywo, jaki jest poziom, jaki jest ekwipunek.
Granice modeli: gra Web2, hybryda Web3, fully on-chain
Podział według kryterium wykonania: „tokenizowane aktywa” i „reguły oraz state w kontraktach” to różne modele.
Gry Web2: stan (postęp, ekwipunek, parametry postaci) jest przechowywany i aktualizowany na scentralizowanych serwerach.
Gry on-chain: działania i/lub stan są utrwalane w blockchainie, a reguły wykonują smart kontrakty.
Hybryda Web3: aktywa są tokenizowane (NFT/tokeny), ale istotna część logiki i postępu pozostaje off-chain.
Fully on-chain: blockchain działa jako warstwa wykonania: logika i state są umieszczone w kontraktach, interfejsy mogą być różne.
Kluczowa teza: obecność NFT nie gwarantuje zachowania użyteczności. Użyteczność utrzymuje się tylko wtedy, gdy reguły użycia i/lub krytyczny state są zapisane w kontraktach albo istnieje kompatybilny klient, który odczytuje kontraktowy state i wykonuje te same reguły.
Prawa do aktywów: „w bazie” kontra „w portfelu”
Posiadanie tokena i istnienie użyteczności w grze to różne stany, ponieważ określają je różne warstwy.
Web2: aktywo jako wpis w systemie dewelopera
Przedmiot istnieje jako rekord w bazie, a dostęp — jako prawo konta do korzystania z funkcji usługi.
- Konto i zasady platformy określają, które przedmioty i tryby są dostępne.
- Blokada konta lub zamknięcie usługi zwykle przerywają dostęp do przedmiotów i postępu.
- Transfer i handel są częściej ograniczone zasadami produktu i infrastrukturą studia.
Konsekwencja: aktywo pozostaje wpisem w bazie, a nie niezależnym obiektem poza usługą.
Web3: aktywo jako token (NFT/token) na adresie portfela
Właściciel kontroluje token kluczami, ale użyteczność zależy od tego, gdzie wykonywane są reguły użycia tokena.
- Token może pozostać niezależnie od konta w grze, ponieważ zapis znajduje się w sieci.
- Jeśli reguły użycia tokena narzuca serwer, studio może wyłączyć użyteczność, nie naruszając samego tokena.
- Po zamknięciu usługi cena tokena może spaść, jeśli nie ma kompatybilnych klientów lub on-chain reguł użycia.
Konsekwencja: token może pozostać na adresie, ale „użyteczność w grze” znika po wyłączeniu serwerowych reguł i postępu.
Rozróżnienie: „NFT w portfelu” oznacza posiadanie tokena. „Token daje prawa w grze” zależy od warstwy, w której opisano i wykonuje się reguły użycia.
Kluczowa myśl: NFT może pozostać, nawet jeśli użyteczność przestała być obsługiwana przez serwer.
Postęp i weryfikacje: serwerowy state vs kontraktowy state
Kluczowe pytanie: gdzie aktualizowany jest state i która warstwa potwierdza przejścia stanu — serwer czy smart kontrakt.
Serwerowy state: postęp jest przechowywany w bazie usługi, a „oficjalną wersję” ustala serwer.
Kontraktowy state: postęp jest utrwalany w danych smart kontraktu i zdarzeniach sieci, a przejścia są sprawdzane przez logikę kontraktu.
| Co jest porównywane | Serwerowy state | Kontraktowy state |
|---|---|---|
| Gdzie przechowywany jest postęp | Baza danych usługi | Dane kontraktu + zdarzenia sieci |
| Kto potwierdza przejścia | Logika serwera i zasady usługi | Logika smart kontraktu (co jest dozwolone, a co zabronione) |
| Kto ustala wersję końcową | Serwer jako jedyny arbiter | Sieć i kontrakt jako źródło prawdy |
| Zmiany administracyjne | Możliwe (np. cofnięcie przyznania nagrody) | Ograniczone regułami kontraktu i transakcjami |
| Jak potwierdzany jest wynik | Na podstawie danych usługi i konta | Na podstawie danych sieci (state kontraktu i zdarzeń) |
| Jeśli usługa jest wyłączona | Postęp i „oficjalna wersja” mogą zniknąć razem z bazą | State i zdarzenia pozostają w sieci, interfejs może się zmienić |
Przykład: jeśli wynik sezonu (ranking i nagroda) jest zapisany on-chain, można go potwierdzić na podstawie danych sieci nawet po zmianie klienta; jeśli wynik sezonu jest przechowywany na serwerze, „oficjalna wersja” znika po wyłączeniu usługi.
Kompromis: on-chain prawa i on-chain wyniki, off-chain rozgrywka
- On-chain: własność, rzadkie nagrody i wyniki sezonów (to, co trzeba potwierdzać niezależnie od serwera).
- Off-chain: działania o wysokiej częstotliwości (walka, przemieszczanie, matchmaking) dla szybkości i UX.
- Konsekwencja: on-chain utrwala rzadkie, ale istotne zdarzenia, a nie każde działanie rozgrywki.
Im więcej praw i wyników końcowych jest zapisanych w kontraktach, tym mniejsza zależność od serwerów przy potwierdzaniu własności i rezultatów sezonowych.
Scenariusz wyłączenia usługi: co traci się w każdym modelu
Wyłączenie serwerów wpływa na aktywa i postęp w różny sposób, ponieważ w różnych modelach inaczej wygląda źródło prawdy.
Web2: wyłączenie infrastruktury zatrzymuje aktualizacje serwerowego state i dostarczanie danych kontu.
Konsekwencja: dostęp do postępu i przedmiotów zwykle kończy się razem z usługą.
Hybryda Web3: NFT pozostaje na adresie jako zapis w sieci, ale elementy serwerowe (postęp, tryby, reguły użycia) mogą zniknąć.
Konsekwencja: token istnieje, ale użyteczność ustaje po wyłączeniu serwerów.
Fully on-chain: logika i state są w kontraktach, więc dane pozostają w sieci niezależnie od jednej firmy.
Ograniczenie: wygodny dostęp zależy od aplikacji klienckich i infrastruktury odczytu danych (RPC i indeksatorów).
Ograniczenia on-chain: opłaty, opóźnienia, UX i ryzyko kontraktów
On-chain zwiększa weryfikowalność, ale dodaje opłaty, opóźnienia i wymagania związane z zarządzaniem kluczami.
- Przepustowość i opóźnienia: zapis działań wymaga transakcji i potwierdzeń.
- Koszt operacji: przechowywanie i aktualizacja state on-chain może być kosztowne.
- Bariery UX: portfel, klucze, podpisy i odzyskiwanie dostępu to osobna warstwa ryzyka.
- Infrastruktura dostępu: RPC, indeksatory i interfejsy wpływają na wygodę i dostępność odczytu state.
- Bezpieczeństwo kontraktów: błędy kodu i niewłaściwe uprawnienia prowadzą do nieodwracalnych skutków dla state i aktywów.
Konsekwencja dla game design: częste mikro-działania rzadko przenosi się on-chain; częściej on-chain utrwala rzadkie, ale istotne zdarzenia (prawa, nagrody, wyniki sezonów).
Powód popularności hybrydy: blockchain jest używany do praw i zdarzeń ekonomicznych, a rozgrywkę o wysokiej częstotliwości pozostawia się off-chain, aby uniknąć opłat i opóźnień przy każdym działaniu.
Kluczowy kompromis: weryfikowalność on-chain jest „opłacana” opłatą i tarciem w UX.
Kryteria wyboru: kiedy on-chain daje wartość, a kiedy nie
Filtr architektoniczny: gdzie liczą się prawa do aktywów i weryfikowalne wyniki, a gdzie ważniejsza jest szybkość i płynny UX.
On-chain częściej ma sens
Gdy wartość jest powiązana z własnością aktywa, pochodzeniem i rynkiem wtórnym.
- Przedmioty kolekcjonerskie i karty, gdzie liczy się rynek wtórny.
- Ekonomie zasobów i crafting z regułami możliwymi do sprawdzenia po zdarzeniach sieci.
- Długowieczne światy, gdzie krytyczne jest zachowanie praw do aktywów i wyników sezonów.
Web2 częściej jest bardziej racjonalne
Gdy ważniejsza jest szybkość, minimalne tarcie i brak opłat przy każdym działaniu.
- Gatunki real-time (strzelanki, akcja), gdzie opóźnienie jest krytyczne.
- Gry casualowe z masowym onboardingiem bez portfeli i podpisów.
- Projekty, w których przedmioty nie mają wartości poza usługą.
Przykłady (punkty odniesienia podejść)
To nie jest rekomendacja ani ocena jakości. Celem sekcji jest pokazanie, jak rynek zwykle nazywa różne architektury.
Weryfikacja według kryteriów: (1) czy postęp jest przechowywany na koncie czy w kontrakcie? (2) czy istnieje alternatywny klient/podgląd state bez oficjalnej strony? (3) czy użyteczność NFT jest określana przez kontrakt czy reguły serwerowe?
- Tokenizowane aktywa (często hybryda) → przedmioty i postacie jako NFT, a rozgrywka i postęp — off-chain.
- Formaty ekonomiczne i kolekcjonerskie → częściej utrwalają on-chain prawa do aktywów i reguły rynku wokół aktywów.
- Kierunki fully on-chain → próbują utrzymać reguły i state w kontraktach, a klient — jako interfejs do danych sieci.
Kryterium weryfikacji: ważniejsze jest miejsce przechowywania postępu i warstwa wykonywania reguł niż obecność NFT.
Trzy częste błędy w postrzeganiu
Błędy oczekiwań zwykle wynikają z mieszania „posiadania tokena” z „działającą użytecznością” i „źródłem prawdy”.
„Jest NFT — więc gry nie da się zamknąć”
Token może istnieć w sieci, a serwerowa rozgrywka i serwerowy postęp mogą zniknąć.
- Posiadanie tokena nie tworzy obowiązku usługi utrzymywania reguł gry.
- Ryzyko określa miejsce przechowywania postępu i miejsce wykonywania reguł użycia tokena.
Konsekwencja: weryfikację należy zaczynać od postępu i reguł, a nie od obecności NFT.
„On-chain = w pełni zdecentralizowane”
On-chain może być używane punktowo: dla aktywów, ale nie dla postępu i reguł meczu.
- Aktywa on-chain nie oznaczają postępu on-chain.
- Model hybrydowy może zachowywać krytyczne zależności od serwerów.
Konsekwencja: „źródło prawdy” dla postępu i reguł należy szukać w serwerze lub w kontrakcie.
„Fully on-chain nie ma ograniczeń”
Kontraktowy state pozostaje w sieci, ale opłaty, opóźnienia i dostęp przez infrastrukturę odczytu wpływają na UX.
- Opłaty i potwierdzenia ograniczają częstotliwość działań on-chain.
- Dostępność klientów, RPC i indeksatorów wpływa na wygodę odczytu state.
Konsekwencja: warto oceniać liczbę działań on-chain i możliwość podglądu state bez jednego frontendu.
FAQ
Czym jest on-chain gaming?
Jaka jest różnica między grami Web2 i Web3 prostymi słowami?
Co stanie się z NFT, jeśli gra zostanie zamknięta?
Czy można grać w gry Web3 bez portfela?
Czy można zachować postęp bez serwerów?
Dlaczego gier fully on-chain jest na razie mało?
Końcowa weryfikacja: on-chain vs Web2 w trzech punktach
Ocena modelu sprowadza się do jednego pytania: gdzie znajduje się „źródło prawdy” dla postępu i reguł.
- Postęp: wynik sezonu i kluczowe nagrody są zapisywane w kontrakcie albo pozostają w bazie usługi.
- Reguły: przejścia state są potwierdzane przez smart kontrakt albo logikę serwera.
- Ryzyko wyłączenia: po zniknięciu usługi pozostają wyłącznie dane sieci i kompatybilny dostęp do nich.
Jeśli postęp i reguły żyją na serwerze, elementy on-chain pozostają aktywami, ale nie zachowują „oficjalnej wersji” gry.