Criterio di confronto: dove viene conservato lo state e dove vengono eseguite le regole
«On-chain games vs Web2 games» — confronto tra l’architettura dei giochi on-chain e dei giochi Web2: dove vengono eseguite le regole e dove viene conservato lo state di gioco (progressi, inventario, parametri del personaggio).
La differenza chiave tra «giochi con NFT» e fully on-chain è che, nel primo caso, il token può essere on-chain, mentre progressi e regole restano sul server.
- Web2 → oggetti e progressi sono record nel database dello sviluppatore; l’accesso è determinato dall’account e dalle regole del servizio.
- On-chain → una parte della logica e/o dello state viene registrata nella blockchain; gli asset possono essere NFT e le azioni possono essere transazioni.
- Ibrido Web3 → l’NFT può essere conservato nel wallet, ma gameplay e progressi di solito vengono aggiornati sul server.
- Fully on-chain → regole e state si trovano negli smart contract; le applicazioni client possono cambiare, mentre le regole di esecuzione e lo state del contratto (eventi e record del contratto) restano nella rete.
Conclusione chiave: con lo spegnimento dei server Web2, accesso e progressi di solito cessano. In un ibrido Web3 l’NFT spesso resta nel wallet, ma l’utilità di gioco scompare se regole d’uso e progressi erano server-side.
La «fonte di verità» è il livello che conserva i diritti sull’asset e lo state finale: server/database dello studio oppure smart contract e dati della rete.
Aggiornamento: chiarite le definizioni di ibrido Web3 e fully on-chain, aggiunti criteri per verificare la «fonte di verità» e le conseguenze dello scenario “server off”.
Conclusione in 4 punti: Web2, ibrido e fully on-chain
Criteri di confronto: dove vengono conservati i progressi (state) e chi convalida le regole (server o smart contract).
- Conta non la presenza di NFT, ma dove vengono conservati i progressi e il livello in cui vengono eseguite le regole.
- Web2 → il server è l’unica fonte di verità e l’unico punto di guasto.
- Ibrido Web3 → il token può restare nel wallet, ma le regole d’uso sono spesso definite dal server.
- Fully on-chain → regole e state nei contratti, il client è un’interfaccia ai dati della rete.
Confronto dei modelli: asset, progressi, dipendenza dal server
Confronto per livelli: fonte di verità, asset, progressi, dipendenza dai server e conseguenze dello spegnimento del servizio.
| Parametro | Web2 | Ibrido Web3 (parzialmente on-chain) |
Fully on-chain |
|---|---|---|---|
| Fonte di verità | Server/database dello studio | Server + blockchain per una parte di diritti/asset | Smart contract e dati della rete |
| Asset | Record in-game | NFT/token nel wallet; l’utilità è spesso definita dal server | NFT/token + regole d’uso nel contratto |
| Progressi (state) | Server-side | Di solito server-side | On-chain (state del contratto) |
| «Server spento» | Accesso e progressi di solito cessano | L’NFT può restare, ma modalità/regole/progressi possono scomparire | Regole e state restano nella rete, l’interfaccia può cambiare |
| UX/velocità | Massimi | Medi (wallet, firme) | Compromesso (commissioni, latenza, infrastruttura di accesso) |
| Rischi principali | Centralizzazione: lo studio può cambiare regole e accesso | Il token esiste, ma l’utilità dipende dai server | Sicurezza dei contratti + scalabilità e UX |
Termini per la lettura: NFT, on-chain/off-chain, smart contract, state
Set minimo di concetti per confrontare: cosa è un asset, dove viene conservato lo state e dove vengono eseguite le regole.
- NFT — token unico sulla blockchain che conferma la proprietà di un oggetto digitale (ad esempio, un item).
- Smart contract — codice sulla blockchain che esegue le regole e conserva/aggiorna i dati.
- On-chain — azione o dati vengono registrati nella rete blockchain.
- Off-chain — azione o dati vengono conservati fuori dalla blockchain (server, client, database privato).
- Fully on-chain — logica e stato del gioco sono sulla blockchain; il client è un’interfaccia ai dati e alle regole del contratto.
- Fonte di verità — livello che determina lo stato finale: chi possiede l’asset, quale livello, quale inventario.
Confini dei modelli: gioco Web2, ibrido Web3, fully on-chain
Separazione per criterio di esecuzione: «asset tokenizzati» e «regole e state nei contratti» sono modelli diversi.
Giochi Web2: lo stato (progressi, inventario, parametri del personaggio) viene conservato e aggiornato su server centralizzati.
Giochi on-chain: azioni e/o stato vengono registrati nella blockchain e le regole vengono eseguite dagli smart contract.
Ibrido Web3: gli asset sono tokenizzati (NFT/token), ma una parte sostanziale della logica e dei progressi resta off-chain.
Fully on-chain: la blockchain viene usata come livello di esecuzione: logica e state sono nei contratti, le interfacce possono essere diverse.
Tesi chiave: la presenza di NFT non garantisce la conservazione dell’utilità. L’utilità si conserva solo se le regole d’uso e/o lo state critico sono fissati nei contratti, oppure se esiste un client compatibile che legge lo state del contratto ed esegue le stesse regole.
Diritti sugli asset: «nel database» vs «nel wallet»
Possedere un token e avere utilità di gioco sono stati diversi, perché dipendono da livelli diversi.
Web2: asset come record nel sistema dello sviluppatore
L’item esiste come riga nel database e l’accesso è un diritto dell’account a usare le funzioni del servizio.
- Account e regole della piattaforma determinano quali item e modalità sono disponibili.
- Il blocco dell’account o la chiusura del servizio di solito interrompono l’accesso a item e progressi.
- Trasferimento e trading sono spesso limitati dalle regole del prodotto e dall’infrastruttura dello studio.
Conseguenza: l’asset resta un record nel database, non un oggetto indipendente fuori dal servizio.
Web3: asset come token (NFT/token) su un indirizzo wallet
Il proprietario controlla il token con le chiavi, ma l’utilità dipende da dove vengono eseguite le regole d’uso del token.
- Il token può restare indipendentemente dall’account del gioco, perché il record è nella rete.
- Se le regole d’uso del token sono definite dal server, lo studio può disattivare l’utilità senza toccare il token stesso.
- Dopo la chiusura del servizio, il prezzo del token può scendere se non esistono client compatibili o regole d’uso on-chain.
Conseguenza: il token può restare sull’indirizzo, ma la «utilità di gioco» scompare con lo spegnimento di regole e progressi server-side.
Distinzione: «NFT nel wallet» significa possesso del token. «Il token dà diritti di gioco» dipende dal livello in cui le regole sono descritte ed eseguite.
Punto chiave: l’NFT può restare anche se l’utilità non viene più gestita dal server.
Progressi e verifiche: state server-side vs state del contratto
Domanda chiave: dove viene aggiornato lo state e quale livello conferma i passaggi di stato — server o smart contract.
State server-side: i progressi sono conservati nel database del servizio, la «versione ufficiale» è definita dal server.
State del contratto: i progressi sono registrati nei dati dello smart contract e negli eventi della rete, i passaggi sono verificati dalla logica del contratto.
| Cosa viene confrontato | State server-side | State del contratto |
|---|---|---|
| Dove sono conservati i progressi | Database del servizio | Dati del contratto + eventi della rete |
| Chi conferma i passaggi | Logica del server e regole del servizio | Logica dello smart contract (cosa è permesso e cosa è vietato) |
| Chi definisce la versione finale | Il server come unico arbitro | La rete e il contratto come fonte di verità |
| Modifiche admin | Possibili (ad esempio, rollback dell’assegnazione di una ricompensa) | Limitate dalle regole del contratto e dalle transazioni |
| Come viene confermato il risultato | Dai dati del servizio e dall’account | Dai dati della rete (state del contratto ed eventi) |
| Se il servizio è disattivato | I progressi e la «versione ufficiale» possono sparire insieme al database | State ed eventi restano nella rete, l’interfaccia può cambiare |
Esempio: se l’esito di una stagione (ranking e ricompensa) è registrato on-chain, può essere verificato dai dati della rete anche con un client diverso; se l’esito della stagione è conservato sul server, la «versione ufficiale» scompare con lo spegnimento del servizio.
Compromesso: diritti on-chain e risultati on-chain, gameplay off-chain
- On-chain: proprietà, ricompense rare e risultati di fine stagione (ciò che serve confermare indipendentemente dal server).
- Off-chain: azioni ad alta frequenza (combattimento, movimento, matchmaking) per velocità e UX.
- Conseguenza: on-chain fissa eventi rari ma significativi, non ogni singola azione di gameplay.
Quanto più diritti e risultati finali vengono registrati nei contratti, tanto minore è la dipendenza dai server per confermare proprietà e risultati stagionali.
Scenario di spegnimento del servizio: cosa si perde in ogni modello
Lo spegnimento dei server incide su asset e progressi in modo diverso, perché la fonte di verità cambia tra i modelli.
Web2: lo spegnimento dell’infrastruttura interrompe l’aggiornamento dello state server-side e la distribuzione dei dati all’account.
Conseguenza: accesso a progressi e oggetti di solito si interrompe insieme al servizio.
Ibrido Web3: l’NFT resta sull’indirizzo come record nella rete, ma gli elementi server-side (progressi, modalità, regole d’uso) possono scomparire.
Conseguenza: il token esiste, ma l’utilità cessa con lo spegnimento dei server.
Fully on-chain: logica e state sono nei contratti, quindi i dati restano nella rete indipendentemente da una singola azienda.
Limite: l’accesso comodo dipende dalle applicazioni client e dall’infrastruttura di lettura dei dati (RPC e indexer).
Limiti dell’on-chain: commissioni, ritardi, UX e rischio dei contratti
On-chain aumenta la verificabilità, ma aggiunge commissioni, ritardi e requisiti di gestione delle chiavi.
- Throughput e ritardi: la registrazione delle azioni richiede transazioni e conferme.
- Costo delle operazioni: conservare e aggiornare lo state on-chain può essere costoso.
- Barriere UX: wallet, chiavi, firme e recupero dell’accesso sono un livello separato di rischi.
- Infrastruttura di accesso: RPC, indexer e interfacce influenzano comodità e disponibilità della lettura dello state.
- Sicurezza dei contratti: bug del codice e permessi errati portano a conseguenze irreversibili per state e asset.
Conseguenza per il game design: le micro-azioni frequenti raramente vengono spostate on-chain; più spesso on-chain fissa eventi rari ma significativi (diritti, ricompense, risultati di fine stagione).
Motivo della popolarità dell’ibrido: la blockchain viene usata per diritti ed eventi economici, mentre il gameplay ad alta frequenza resta off-chain per evitare commissioni e ritardi a ogni azione.
Compromesso chiave: la verificabilità on-chain si paga con commissioni e frizione in UX.
Criteri di scelta: quando l’on-chain dà valore, quando no
Filtro per architettura: dove contano diritti sugli asset e risultati verificabili, e dove contano di più velocità e UX senza attriti.
On-chain è più spesso giustificato
Quando il valore è legato alla proprietà dell’asset, alla provenienza e al mercato secondario.
- Oggetti e carte collezionabili, dove conta il mercato secondario.
- Economie di risorse e crafting con regole verificabili dagli eventi della rete.
- Mondi di lunga durata, dove è critico conservare diritti sugli asset e risultati di fine stagione.
Web2 è più spesso più razionale
Quando contano di più la velocità, l’attrito minimo e l’assenza di commissioni a ogni azione.
- Generi real-time (shooter, action), dove la latenza è critica.
- Giochi casual con onboarding di massa senza wallet e firme.
- Progetti in cui gli oggetti non hanno valore fuori dal servizio.
Esempi (punti di riferimento per gli approcci)
Non è una raccomandazione né una valutazione della qualità. L’obiettivo della sezione è mostrare come il mercato di solito definisce architetture diverse.
Verifica con i criteri: (1) i progressi sono conservati nell’account o nel contratto? (2) esiste un client alternativo/una lettura dello state senza il sito ufficiale? (3) l’utilità dell’NFT è definita dal contratto o da regole server-side?
- Asset tokenizzati (spesso ibrido) → oggetti e personaggi come NFT, mentre gameplay e progressi sono off-chain.
- Formati economici e collezionabili → più spesso fissano on-chain i diritti sugli asset e le regole del mercato attorno agli asset.
- Direzioni fully on-chain → cercano di mantenere regole e state nei contratti, con il client come interfaccia ai dati della rete.
Criterio di verifica: contano di più dove sono conservati i progressi e il livello di esecuzione delle regole, non la presenza di NFT.
Tre errori comuni di percezione
Gli errori di aspettative di solito nascono dal mescolare «possesso del token» con «utilità funzionante» e «fonte di verità».
«C’è un NFT — quindi il gioco non può essere chiuso»
Il token può esistere nella rete, mentre gameplay e progressi server-side possono scomparire.
- Possedere un token non crea un obbligo per il servizio di mantenere le regole di gioco.
- Il rischio dipende da dove sono conservati i progressi e da dove vengono eseguite le regole d’uso del token.
Conseguenza: la verifica deve iniziare da progressi e regole, non dalla presenza di NFT.
«On-chain = completamente decentralizzato»
On-chain può essere usato in modo puntuale: per gli asset, ma non per progressi e regole del match.
- Asset on-chain non significano progressi on-chain.
- Un modello ibrido può mantenere dipendenze critiche dai server.
Conseguenza: la «fonte di verità» per progressi e regole va cercata nel server o nel contratto.
«Fully on-chain non ha limiti»
Lo state del contratto resta nella rete, ma commissioni, ritardi e accesso tramite infrastruttura di lettura incidono sulla UX.
- Commissioni e conferme limitano la frequenza delle azioni on-chain.
- Disponibilità di client, RPC e indexer influisce sulla comodità di lettura dello state.
Conseguenza: conta valutare il numero di azioni on-chain e la possibilità di vedere lo state senza un solo frontend.
FAQ
Che cos’è l’on-chain gaming?
Qual è la differenza tra giochi Web2 e Web3 in parole semplici?
Cosa succede agli NFT se il gioco chiude?
È possibile giocare ai giochi Web3 senza wallet?
È possibile conservare i progressi senza server?
Perché ci sono ancora pochi giochi fully on-chain?
Verifica finale: on-chain vs Web2 in base a tre segnali
La valutazione del modello si riduce a una domanda: dov’è la «fonte di verità» per progressi e regole.
- Progressi: esito della stagione e ricompense chiave vengono registrati nel contratto oppure restano nel database del servizio.
- Regole: i passaggi di state sono confermati dallo smart contract oppure dalla logica del server.
- Rischio di spegnimento: con la scomparsa del servizio restano solo i dati della rete e un accesso compatibile ad essi.
Se progressi e regole vivono sul server, gli elementi on-chain restano asset, ma non preservano la «versione ufficiale» del gioco.