Criterio de comparación: dónde se almacena el state y dónde se ejecutan las reglas
«On-chain games vs Web2 games» — comparación de la arquitectura de juegos on-chain y juegos Web2: dónde se ejecutan las reglas y dónde se almacena el state del juego (progreso, inventario, parámetros del personaje).
La diferencia clave entre «juegos con NFT» y fully on-chain es que, en un caso, el token puede estar on-chain, pero el progreso y las reglas permanecen en el servidor.
- Web2 → objetos y progreso: registros en la base de datos del desarrollador; el acceso se determina por la cuenta y las reglas del servicio.
- On-chain → parte de la lógica y/o del estado se fija en la blockchain; los activos pueden ser NFT, y las acciones, transacciones.
- Híbrido Web3 → el NFT puede almacenarse en la cartera, pero el gameplay y el progreso suelen actualizarse en el servidor.
- Fully on-chain → las reglas y el state están en los smart contracts; las aplicaciones cliente pueden cambiar, pero las reglas de ejecución y el state contractual (eventos y registros del contrato) permanecen en la red.
Si se apagan los servidores Web2, el acceso y el progreso normalmente se interrumpen. En un híbrido Web3, el NFT a menudo se conserva en la cartera, pero la utilidad de juego desaparece si las reglas de uso y el progreso dependían del servidor.
La «fuente de la verdad» es la capa que almacena los derechos sobre el activo y el state final: servidor/BD del estudio o smart contract y datos de la red.
Actualización: se ajustaron las definiciones de híbrido Web3 y fully on-chain, se añadieron criterios para verificar la «fuente de la verdad» y se precisaron las consecuencias del escenario «server off».
Conclusión en 4 puntos: Web2, híbrido y fully on-chain
Criterios de comparación: dónde se almacena el progreso (state) y quién valida las reglas (servidor o smart contract).
- No importa la presencia de NFT, sino dónde se almacena el progreso y la capa que ejecuta las reglas.
- Web2 → el servidor es la única fuente de la verdad y el punto único de fallo.
- Híbrido Web3 → el token puede conservarse en la cartera, pero las reglas de uso suelen establecerse en el servidor.
- Fully on-chain → reglas y state en los contratos; el cliente es una interfaz hacia los datos de la red.
Comparación de modelos: activos, progreso, dependencia del servidor
Comparación por capas: fuente de la verdad, activos, progreso, dependencia de servidores y consecuencias de apagar el servicio.
| Parámetro | Web2 | Híbrido Web3 (parcialmente on-chain) |
Fully on-chain |
|---|---|---|---|
| Fuente de la verdad | Servidor/BD del estudio | Servidor + blockchain para parte de los derechos/activos | Smart contracts y datos de la red |
| Activos | Registro dentro del juego | NFT/tokens en la cartera; la utilidad suele definirse en el servidor | NFT/tokens + reglas de uso en el contrato |
| Progreso (state) | De servidor | Normalmente de servidor | On-chain (state del contrato) |
| «Apagaron el servidor» | El acceso y el progreso normalmente se interrumpen | El NFT puede conservarse, pero los modos/reglas/progreso pueden desaparecer | Las reglas y el state se conservan en la red; la interfaz puede cambiar |
| UX/velocidad | Máximas | Medias (cartera, firmas) | Compromiso (comisiones, latencia, infraestructura de acceso) |
| Riesgos principales | Centralización: el estudio puede cambiar reglas y acceso | El token existe, pero la utilidad depende de los servidores | Seguridad de contratos + escalabilidad y UX |
Términos para leer: NFT, on-chain/off-chain, smart contract, state
Conjunto mínimo de conceptos para comparar: qué es un activo, dónde se almacena el state y dónde se ejecutan las reglas.
- NFT — token único en la blockchain que confirma la propiedad de un objeto digital (por ejemplo, un ítem).
- Smart contract — código en la blockchain que ejecuta reglas y almacena/actualiza datos.
- On-chain — la acción o los datos se registran en la red blockchain.
- Off-chain — la acción o los datos se almacenan fuera de la blockchain (servidor, cliente, BD cerrada).
- Fully on-chain — la lógica y el estado del juego están en la blockchain; el cliente es una interfaz hacia los datos y las reglas del contrato.
- Fuente de la verdad — la capa que determina el estado final: quién posee el activo, qué nivel, qué inventario.
Límites de los modelos: juego Web2, híbrido Web3, fully on-chain
Separación por criterio de ejecución: «activos tokenizados» y «reglas y state en contratos» son modelos distintos.
Juegos Web2: el estado (progreso, inventario, parámetros del personaje) se almacena y actualiza en servidores centralizados.
Juegos on-chain: las acciones y/o el estado se registran en la blockchain y las reglas se ejecutan mediante smart contracts.
Híbrido Web3: los activos se tokenizan (NFT/tokens), pero una parte significativa de la lógica y del progreso permanece off-chain.
Fully on-chain: la blockchain se usa como capa de ejecución: la lógica y el state están en contratos, y las interfaces pueden variar.
Idea central: la presencia de NFT no garantiza la conservación de la utilidad. La utilidad solo se conserva si las reglas de uso y/o el state crítico están fijados en contratos, o si existe un cliente compatible que lea el state contractual y ejecute las mismas reglas.
Derechos sobre activos: «en la BD» vs «en la cartera»
La propiedad del token y la existencia de utilidad de juego son estados distintos, porque los determinan capas diferentes.
Web2: activo como registro en el sistema del desarrollador
El ítem existe como una fila en la base de datos, y el acceso como el derecho de la cuenta a usar funciones del servicio.
- La cuenta y las reglas de la plataforma determinan qué ítems y modos están disponibles.
- El bloqueo de la cuenta o el cierre del servicio normalmente interrumpen el acceso a ítems y progreso.
- La transferencia y el comercio suelen estar limitados por reglas del producto y la infraestructura del estudio.
Consecuencia: el activo sigue siendo un registro en la BD, no un objeto independiente fuera del servicio.
Web3: activo como token (NFT/token) en la dirección de la cartera
El propietario controla el token con las claves, pero la utilidad depende de dónde se ejecutan las reglas de uso del token.
- El token puede conservarse independientemente de la cuenta del juego, porque el registro está en la red.
- Si el servidor define las reglas de uso, el estudio puede desactivar la utilidad sin afectar al token.
- Tras el cierre del servicio, el precio del token puede caer si no hay clientes compatibles o reglas on-chain de uso.
Consecuencia: el token puede permanecer en la dirección, pero la «utilidad de juego» desaparece al apagarse reglas y progreso de servidor.
Diferenciación: «NFT en la cartera» significa propiedad del token. «El token otorga derechos en el juego» depende de la capa donde se describen y ejecutan las reglas de uso.
Idea clave: el NFT puede conservarse incluso si la utilidad dejó de mantenerse en el servidor.
Progreso y verificaciones: state de servidor vs state de contrato
Pregunta clave: dónde se actualiza el state y qué capa confirma los cambios de estado: servidor o smart contract.
State de servidor: el progreso se almacena en la base de datos del servicio; el servidor define la «versión oficial».
State de contrato: el progreso se fija en los datos del smart contract y en los eventos de la red; los cambios se verifican por la lógica del contrato.
| Qué se compara | State de servidor | State de contrato |
|---|---|---|
| Dónde se almacena el progreso | Base de datos del servicio | Datos del contrato + eventos de la red |
| Quién confirma los cambios | Lógica del servidor y reglas del servicio | Lógica del smart contract (qué está permitido y qué está prohibido) |
| Quién define la versión final | El servidor como único árbitro | La red y el contrato como fuente de la verdad |
| Cambios administrativos | Posibles (por ejemplo, revertir una recompensa) | Limitados por las reglas del contrato y las transacciones |
| Cómo se confirma el resultado | Por datos del servicio y de la cuenta | Por datos de la red (state del contrato y eventos) |
| Si el servicio se apaga | El progreso y la «versión oficial» pueden desaparecer junto con la BD | El state y los eventos permanecen en la red; la interfaz puede cambiar |
Ejemplo: si el resultado de la temporada (ranking y recompensa) está registrado on-chain, puede confirmarse por los datos de la red incluso si cambia el cliente; si el resultado está en el servidor, la «versión oficial» desaparece al apagar el servicio.
Compromiso: derechos on-chain e hitos on-chain, gameplay off-chain
- On-chain: propiedad, recompensas raras y resultados de temporada (lo que conviene confirmar sin depender del servidor).
- Off-chain: acciones de alta frecuencia (combate, movimiento, matchmaking) por velocidad y UX.
- Consecuencia: on-chain fija eventos poco frecuentes pero significativos, no cada acción del gameplay.
Cuanto más derechos y resultados finales se registran en contratos, menor es la dependencia de servidores para confirmar propiedad y resultados de temporada.
Escenario de apagado del servicio: qué se pierde en cada modelo
El apagado de servidores afecta de manera distinta a activos y progreso, porque la fuente de la verdad difiere entre modelos.
Web2: apagar la infraestructura detiene la actualización del state de servidor y la entrega de datos a la cuenta.
Consecuencia: el acceso al progreso y a los ítems normalmente se interrumpe junto con el servicio.
Híbrido Web3: el NFT permanece en la dirección como registro en la red, pero los elementos de servidor (progreso, modos, reglas de uso) pueden desaparecer.
Consecuencia: el token existe, pero la utilidad se interrumpe al apagarse los servidores.
Fully on-chain: la lógica y el state están en contratos, por lo que los datos permanecen en la red independientemente de una sola empresa.
Limitación: el acceso cómodo depende de aplicaciones cliente e infraestructura de lectura de datos (RPC e indexadores).
Limitaciones on-chain: comisiones, retrasos, UX y riesgo de contratos
On-chain aumenta la verificabilidad, pero añade comisiones, retrasos y requisitos de gestión de claves.
- Capacidad y retrasos: registrar acciones requiere transacciones y confirmaciones.
- Coste de operaciones: almacenar y actualizar state on-chain puede ser caro.
- Barreras de UX: cartera, claves, firmas y recuperación de acceso: capa adicional de riesgos.
- Infraestructura de acceso: RPC, indexadores e interfaces afectan la comodidad y la disponibilidad de lectura del state.
- Seguridad de contratos: errores de código y permisos incorrectos provocan consecuencias irreversibles para el state y los activos.
Consecuencia para el diseño: las microacciones frecuentes rara vez se trasladan on-chain; más a menudo on-chain fija eventos raros pero significativos (derechos, recompensas, resultados de temporada).
Razón de la popularidad del híbrido: la blockchain se usa para derechos y eventos económicos, y el gameplay de alta frecuencia se deja off-chain para evitar comisiones y retrasos en cada acción.
La verificabilidad on-chain se paga con comisiones y fricción en UX.
Criterios de elección: cuándo on-chain aporta valor y cuándo no
Filtro por arquitectura: dónde importan los derechos sobre activos y resultados verificables, y dónde importa más la velocidad y un UX fluido.
On-chain suele estar justificado
Cuando el valor está vinculado a la propiedad, el origen y el mercado secundario.
- Ítems y cartas coleccionables donde importa el mercado secundario.
- Economías de recursos y crafting con reglas verificables por eventos de red.
- Mundos de larga vida donde es crítico conservar derechos sobre activos y resultados de temporada.
Web2 suele ser más racional
Cuando importa más la velocidad, la mínima fricción y la ausencia de comisiones por acción.
- Géneros en tiempo real (shooters, acción) donde la latencia es crítica.
- Juegos casuales con onboarding masivo sin carteras ni firmas.
- Proyectos donde los ítems no tienen valor fuera del servicio.
Ejemplos (referencias de enfoques)
Esto no es una recomendación ni una evaluación de calidad. El objetivo de la sección es mostrar cómo el mercado suele llamar a distintas arquitecturas.
Verificación por criterios: (1) ¿el progreso se almacena en la cuenta o en el contrato? (2) ¿existe un cliente alternativo/visualización del state sin el sitio oficial? (3) ¿la utilidad del NFT se define por el contrato o por reglas de servidor?
- Activos tokenizados (a menudo híbrido) → ítems y personajes como NFT, mientras que el gameplay y el progreso son off-chain.
- Formatos económicos y coleccionables → con mayor frecuencia fijan on-chain los derechos sobre activos y las reglas de mercado alrededor de ellos.
- Enfoques fully on-chain → intentan mantener reglas y state en contratos, con el cliente como interfaz a los datos de la red.
Criterio de verificación: importa más dónde se almacena el progreso y la capa de ejecución de reglas que la presencia de NFT.
Tres errores frecuentes de percepción
Los errores de expectativas suelen estar relacionados con mezclar «propiedad del token» con «utilidad funcionando» y con la «fuente de la verdad».
«Hay NFT — el juego no se puede cerrar»
El token puede existir en la red, mientras que el gameplay y el progreso de servidor pueden desaparecer.
- La propiedad del token no crea obligación del servicio de mantener las reglas del juego.
- El riesgo lo determina dónde se almacena el progreso y dónde se ejecutan las reglas de uso del token.
Consecuencia: la verificación debe empezar por el progreso y las reglas, no por la existencia de NFT.
«On-chain = totalmente descentralizado»
On-chain puede usarse de forma puntual: para activos, pero no para el progreso y las reglas de la partida.
- Activos on-chain no significan progreso on-chain.
- El modelo híbrido puede mantener dependencias críticas del servidor.
Consecuencia: la «fuente de la verdad» del progreso y las reglas se busca en el servidor o en el contrato.
«Fully on-chain no tiene limitaciones»
El state del contrato permanece en la red, pero comisiones, retrasos y acceso mediante infraestructura de lectura afectan el UX.
- Comisiones y confirmaciones limitan la frecuencia de acciones on-chain.
- La disponibilidad de clientes, RPC e indexadores afecta la comodidad de lectura del state.
Consecuencia: es importante evaluar el número de acciones on-chain y la posibilidad de ver el state sin un solo frontend.
FAQ
¿Qué es on-chain gaming?
¿Cuál es la diferencia entre juegos Web2 y Web3 en palabras simples?
¿Qué pasa con un NFT si el juego cierra?
¿Se puede jugar a juegos Web3 sin cartera?
¿Se puede conservar el progreso sin servidores?
¿Por qué todavía hay pocos juegos fully on-chain?
Verificación final: on-chain vs Web2 en tres señales
La evaluación del modelo se reduce a una pregunta: dónde está la «fuente de la verdad» para el progreso y las reglas.
- Progreso: el resultado de la temporada y las recompensas clave se registran en el contrato o permanecen en la base del servicio.
- Reglas: los cambios de state se confirman por el smart contract o por la lógica del servidor.
- Riesgo de apagado: si el servicio desaparece, solo permanecen los datos de la red y el acceso compatible a ellos.
Si el progreso y las reglas viven en el servidor, los elementos on-chain siguen siendo activos, pero no conservan la «versión oficial» del juego.