Ieri, mentre ero in giro a spulciare le notizie nel mio cerchio, ho visto che gli utenti attivi giornalieri di Pixels hanno superato la soglia dei 153.000, e i ragazzi nel gruppo erano tutti eccitati come se avessero appena beccato un pump, urlando che il bull market è arrivato e che dobbiamo fare il FOMO. Ma io, che da quasi dieci anni mi muovo nel mondo del Web3 e tra le righe di codice, la mia prima reazione non è stata affatto quella di dire "wow, è tutto così esplosivo, devo entrare!", ma piuttosto la mia mente ha iniziato a frullare, e ho pensato a una domanda tecnica che colpisce nel profondo: ci sono decine di migliaia di persone distribuite in vari paesi del mondo, e il server di gioco è programmato per trasmettere lo stato completo della fattoria ogni 100 millisecondi. Se ci pensi bene, da un centro dati a Singapore, quanto tempo ci vorrà per inviare quel pacchetto dati fino ai giocatori in Brasile, tra smartphone e computer? Quanti millisecondi andranno persi in questo processo?
Chi ha mai giocato a quei giochi tradizionali Web2, come la versione multiplayer di 'Stardew Valley', sa che anche con 200 millisecondi di latenza, si sente solo un leggero ritardo nel tagliare gli alberi, e si può comunque divertirsi. Ma Pixels non è un gioco tradizionale; è intrinsecamente legato alla blockchain, il che significa che ogni volta che fai fatica a raccogliere un raccolto raro, devi coniare quell'oggetto come NFT sulla blockchain! Questa finestra di 'conferma sulla blockchain' è fondamentale e distrugge completamente il precedente bilancio economico della semplice sincronizzazione dello stato del server. Oggi, prepariamoci una tazza di tè e analizziamo a fondo l'architettura tecnologica sottostante!
Primo ostacolo: l'illusione dei 100 millisecondi e i limiti fisici del transoceanico.
Come al solito, iniziamo dall'architettura tecnologica di base. Secondo la logica di sincronizzazione dei server di gioco attualmente in uso, Pixels, essendo posizionato come un gioco sociale da fattoria piuttosto rilassato, utilizza probabilmente un modello di 'sincronizzazione dello stato' piuttosto che un 'frame synchronization' estremamente rigoroso. Ma cos'è la sincronizzazione dello stato? In parole povere, il server detiene l'unica 'verità' del mondo, mentre ciò che i client dei giocatori vedono sono solo i 'risultati' inviati dal server; se il server dice che hai piantato, allora hai piantato. Al contrario, la sincronizzazione a frame, utilizzata negli eSport, richiede che ogni client dei giocatori esegua un'istanza di calcolo completa, e se tutti inseriscono le stesse istruzioni, il mondo risultante sarà assolutamente coerente!
Pixels ha scelto la sincronizzazione dello stato, e questa era una scelta scontata; piantare un ortaggio non richiede l'estrema microgestione di un DOTA dove ogni 16,67 millisecondi si deve aggiornare il frame. Un intervallo di broadcast di 100 millisecondi è più che sufficiente per vedere le piante crescere e gli animali muoversi nella mappa!
Ma! Il problema si trova proprio in quella parola 'globale'; guarda come la distribuzione della latenza geografica nel mondo fisico è spaventosa — se considerassimo che il nodo di Singapore ha solo 20 millisecondi, mentre quelli sulla costa occidentale degli Stati Uniti devono sopportare 80 millisecondi, i giocatori europei sono intorno ai 120 millisecondi, e quelli in Sud America possono superare i 200 millisecondi! Ieri, seduto al computer, ho calcolato sulla mia mappa del mondo: supponendo che il team di Pixels fosse abbastanza lungimirante da distribuire nodi server nelle tre aree chiave globali, come Singapore in Asia, Francoforte in Europa e Virginia in America, secondo i dati di qualità di rete forniti dai principali fornitori di servizi cloud, possiamo effettivamente mantenere la latenza compresa tra 20 e 50 millisecondi in ogni area; ma una volta che si attraversa la regione? Si devono affrontare i frutti amari di 100-200 millisecondi di latenza fisica! Ciò significa che se un giocatore di Singapore e uno di Brasile si trovano fortuitamente nella stessa fattoria, il pacchetto di sincronizzazione dello stato deve attraversare l'oceano da Singapore a Virginia e poi faticosamente fino al Brasile, e questa andata e ritorno di latenza facilmente supera i 300 millisecondi!
E il broadcasting è fissato a 100 millisecondi; non è imbarazzante? In realtà, il ritmo dell'intero server sarà bloccato dal giocatore più lento. Le strade davanti al team di progetto sono solo due: o devono abbassare la frequenza di broadcasting, per esempio a 200 millisecondi; o devono costringere i giocatori veloci a aspettare i più lenti. Certo, potrebbero anche provare a 'regionalizzare i server', ma se lo fanno, l'idea di 'server globali uniti' nel Web3 diventerebbe solo una pura strategia di marketing ingannevole!
Secondo ostacolo: calcolare il confuso 'registro on-chain' di 150.000 utenti simultanei.
E non è finita qui; la vera insidia si nasconde nella latenza della blockchain, che è il vero collo di bottiglia! Vedi, il modo in cui Pixels funziona è che carica tutti gli stati di gioco ad alta frequenza e poco rilevanti su server centralizzati off-chain, e solo in caso di eventi chiave che coinvolgono denaro reale, come la creazione di NFT o il trasferimento di token, i dati vengono ancorati sulla catena Ronin! Sappiamo tutti che la catena Ronin è stata progettata appositamente per i giochi, con un tempo medio di conferma di circa 3 secondi e una commissione per singola transazione di circa 0,003 dollari; sembra abbastanza allettante, vero?
Ma non dimenticare, c'è un confronto qui. Se Pixels avesse deciso di lanciarsi sulla rete principale di ETH, sarebbe stato un disastro — anche se ogni stato broadcast fosse stato solo un hash gettato sulla catena, considerando il tempo medio di conferma di blocco di 12 secondi su ETH e le tariffe di gas che partono da 2 dollari, non stiamo più parlando di un gioco, ma di bruciare soldi! E se si fosse lanciato sulla catena BTC, sarebbe stato ancora più surreale; per una conferma dovresti aspettare dieci minuti, con commissioni che partono da 10 dollari! Fratello, pensa a questo: per un gioco che richiede una risposta di 100 millisecondi, dieci minuti su BTC e 12 secondi su ETH sembrano come se avessi ordinato una consegna urgente in città e ti mandassero un carro a traino che arriva lentamente; potresti morire dall'ansia! Questo è il motivo per cui, dopo tanti anni, il cosiddetto 'gioco completamente on-chain' non ha nemmeno un'ombra di diffusione su larga scala, l'infrastruttura di base semplicemente non lo permette!
Essendo un vecchio sviluppatore, non riesco a trattenere la curiosità, così ho simulato una situazione di test di carico estrema: pensa un po', se i 150.000 utenti attivi di Pixels coincidono in un picco, supponendo che ognuno clicchi una sola volta al secondo, che si tratti di muovere qualcosa, piantare un seme o annaffiare, il server dovrà gestire un totale di 150.000 operazioni al secondo! Se questo gioco fosse davvero on-chain come affermano, significherebbe che sulla catena si devono elaborare 150.000 transazioni al secondo, e sai cosa? La rete principale di ETH attualmente supporta al massimo circa 30 TPS; per eseguire questo gioco, dovremmo espandere di 5000 volte! La TPS di BTC è di circa 7, quindi dovremmo espandere di oltre 20.000 volte per reggere il carico!
Quindi, la verità di Pixels non è che sia una questione di scelte multiple; questa architettura mista è l'unica soluzione per la sopravvivenza — i server off-chain devono sopportare ogni seconda 150.000 operazioni ad alta frequenza, mentre sulla catena si gestiscono solo eventi critici, meno dell'1% delle operazioni, circa 1.500 al secondo! A questo punto, i 20 TPS di Ronin, sebbene sembrino un po' stretti, possono comunque funzionare con un po' di tecnologia di impacchettamento, e i 30 TPS di ETH possono andare bene, ma considerando che i costi tra i due differiscono di ben 1000 volte, chi non sceglierebbe l'alternativa più economica, giusto?
Il terzo ostacolo: questa dannata 'sincronizzazione ottimistica' e il periodo di vuoto del commercio internazionale.
Ma non ci si deve rallegrarsi troppo presto, perché c'è un altro enorme problema: la latenza di attesa durante la sincronizzazione dei server off-chain a livello globale! Pixels deve mantenere la coerenza dello stato del gioco tra i server nelle tre regioni, altrimenti si verificheranno eventi 'paranormali' estremamente ridicoli: ad esempio, se in Asia ho già raccolto una zucca pregiata, i giocatori in America vedranno ancora la zucca crescere nel terreno! Se i dati non corrispondono, il sistema economico di gioco potrebbe crollare! Quando sviluppavamo giochi tradizionali Web2, usavamo una replica master-slave di database e elaborazione di flussi di dati CDC; spendere qualche soldo per la larghezza di banda per mantenere la latenza sotto i 50 millisecondi non era affatto un problema. Ma Pixels non può farlo, perché la 'conferma dell'asset blockchain' pende sopra di loro come una spada di Damocle! Qualsiasi stato di cambiamento dell'asset, come quando trovi un oggetto leggendario, anche se il server off-chain sincronizza alla velocità della luce, non conta; deve aspettare che la lunga conferma di 3 secondi sulla catena Ronin venga completata, solo allora sarà finalizzato!
Questo significa che la sincronizzazione dello stato tra i server delle diverse regioni è effettivamente bloccata da questa finestra di conferma di 3 secondi sulla catena. La prassi comune nel settore è quella di implementare un meccanismo di 'sincronizzazione ottimistica': in altre parole, il server presume che l'operazione andrà a buon fine, permettendo al gioco di proseguire, e dopo 3 secondi, se scopre che l'operazione sulla catena è fallita o congestionata, il server riporta forzatamente il tuo stato di gioco indietro! A dire il vero, questo tipo di design mette a dura prova la logica di risoluzione dei conflitti; se non gestito bene, la mentalità dei giocatori potrebbe esplodere!
A questo punto, c'è una logica ancora più cruciale che non ho completamente compreso: come garantiscono la sicurezza assoluta nelle transazioni tra regioni? Immagina questo scenario: un giocatore veterano di Singapore vuole vendere un NFT di una terra molto preziosa a un compratore brasiliano. A livello di server off-chain, si tratta di modificare alcune righe di codice e lo stato della terra si trasferisce immediatamente. Tuttavia, a livello di blockchain, il trasferimento di proprietà legale deve aspettare la conferma del blocco di Ronin, che richiede 3 secondi! Questo crea un pericoloso 'periodo di vuoto' — in quei brevi 3 secondi, il gioco mostra che la terra è già del ragazzo brasiliano, ma sul blockchain explorer risulta ancora di proprietà dell'anziano di Singapore!
Se in quei cruciali 3 secondi uno dei server chiave dovesse andare giù o la rete subisse una forte oscillazione, ci sarebbe un'alta probabilità di perdere lo stato o di generare contraddizioni logiche fatali! Vedi, anche se le transazioni di BTC sono lente come una lumaca e richiedono 10 minuti, una volta confermate, sono definitive e irreversibili; ETH deve aspettare 12 secondi, ma anche quello è un'approvazione finale! Solo Pixels, con questa conferma di 3 secondi sulla catena e la sincronizzazione ottimistica off-chain, ha creato un 'intermediario' estremamente fragile di 'incoerenza temporanea' nel sistema, il che, per un asset finanziario come un NFT di terra che può valere migliaia o addirittura decine di migliaia di dollari, è come camminare su una corda tesa!
Quarto ostacolo: 'teletrasporti' e jitter di rete.
Scaviamo un po' più a fondo nei dettagli hardcore come la volatilità della rete e la perdita di pacchetti; secondo gli attuali standard di misurazione della latenza nel mondo dei giochi online, da 1 a 30 millisecondi è considerato estremamente fluido, da 31 a 50 millisecondi è buono, da 51 a 100 millisecondi è accettabile, ma oltre i 100 millisecondi, si rischia di ricevere una recensione negativa! Pixels è attaccato a questo intervallo di broadcasting di 100 millisecondi, il che significa che se la tua latenza di rete supera i 100 millisecondi, perderai senza dubbio un pacchetto di aggiornamento di stato estremamente importante, e dovrai aspettare il ciclo successivo di 100 millisecondi per 'salvarsi'! Se la tua rete è ancora peggiore e la perdita di pacchetti raggiunge il 5%, significa che per ogni 20 broadcasting del server, ne perderai 1, e sul tuo schermo vedrai i giocatori che coltivano accanto a te 'teletrasportarsi' come fantasmi, o il tuo movimento di zappare bloccarsi a mezz'aria!
Quando sviluppavamo giochi tradizionali, in situazioni come questa, si usava direttamente il protocollo UDP con meccanismi di retransmission, e si implementavano algoritmi di compensazione predittiva sul client; in questo modo si riusciva a ingannare i giocatori facendoli sentire a loro agio. Ma Pixels non può farlo, perché è legato dalla verifica della blockchain; una volta che la previsione dell'azione del client è errata, non puoi semplicemente sovrascrivere con nuovi dati come prima; devi seguire un processo di rollback sulla catena estremamente complesso e costoso, che è un peso insostenibile per il team di progetto!
Il limite e il calcolo finale di un veterano.
Quindi, ciò che monitoro di più ogni giorno non è il chiacchiericcio delle candele K del token, ma se Pixels avrà il coraggio di rendere pubblica la loro mappa di distribuzione globale dei server e il pannello di monitoraggio della latenza in tempo reale! Se davvero si impegnano a installare server di alta qualità nei nodi chiave in Nord America, Europa e Asia, e se possono garantire che la maggior parte dei giocatori avrà una latenza sotto i 100 millisecondi, allora meriterebbero un grande applauso per questa architettura incredibile e matura; ma se, scavando a fondo, scoprissimo che stanno risparmiando, contando solo su un centro server a Singapore e lasciando i giocatori in Europa e America a combattere con latenza di oltre 200 millisecondi, allora l'intera narrativa del 'grande ecosistema globale' sarebbe solo una farsa di marketing per gli investitori! Inoltre, la stabilità del tempo di blocco della catena Ronin è fondamentale — se la catena sembra funzionare bene, ma durante i picchi di raccolta si congestiona, il tempo di blocco può balzare da 3 secondi a 10 secondi o anche più, distruggendo le ipotesi tecniche che consentono una sincronizzazione fluida dello stato off-chain, e l'intero ciclo economico del gioco potrebbe bloccarsi!
In sostanza, se si scava sotto questa facciata tecnologica, si scopre che l'intervallo di 100 millisecondi stabilito da Pixels è fondamentalmente un compromesso tra l'esperienza di gioco dei giocatori e i costi elevati dell'architettura server. Se l'intervallo fosse ridotto a 50 millisecondi, sarebbe certamente più fluido, ma il team dovrebbe noleggiare più server di alta qualità e acquistare larghezza di banda più costosa per le linee internazionali, e questo costo potrebbe facilmente portare il team al fallimento. Ma se l'intervallo fosse esteso a 200 millisecondi, i giocatori percepirebbero il gioco come estremamente 'non reattivo', lento come un prodotto semi-funzionale! Penso che questo numero misterioso di 100 millisecondi sia il punto critico calcolato meticolosamente dal loro team: dopotutto, non stiamo coltivando in un gioco FPS dove ogni millisecondo conta, 100 millisecondi sono già abbastanza per rendere l'animazione della crescita della carota fluida e naturale. Ma non è nemmeno un gioco di carte dove si gioca a turni lenti; non si possono tollerare diversi secondi di latenza! Trovare questo punto di equilibrio ricorda la scelta di Bitcoin di mantenere una conferma di 10 minuti per garantire la sicurezza, mentre Ethereum ha optato per 12 secondi per competere con la disponibilità; alla base ci sono sempre le scelte filosofiche dei migliori architetti!
Le mie conclusioni preliminari, calcolando fino a tardi con carta e penna, sono che la distribuzione globale della latenza di 150.000 utenti in Pixels è probabilmente da 20 millisecondi per i giocatori locali in Asia fino a oltre 200 millisecondi per quelli in Sud America, il che suggerisce un valore mediano che si aggira tra gli 80 e i 120 millisecondi! A dirla tutta, se questo livello di latenza permette ai giocatori di coltivare verdure e raccogliere legna, è accettabile per un gioco di puro relax; ma se il gioco dovesse ambire a qualcosa di più ambizioso, come interazioni in tempo reale ad alta frequenza tra giocatori, o attività PVP che richiedono movimenti precisi, allora questa latenza diventerà un disastro! La radice di tutti questi problemi è la latenza di conferma della blockchain che non può essere evitata e la necessità intrinseca di interazione in tempo reale nei giochi, creando un abisso incolmabile. Finché questo nodo non viene risolto, non possiamo abbassare la guardia. Io continuo a monitorare e calcolare questa situazione economica tecnica, quindi evitiamo le chiacchiere e aspettiamo i dati reali sulla latenza.
