No todos los protocolos Web3 necesitan un token nativo

Al desarrollar un nuevo protocolo, la suposición predeterminada es casi siempre que debe seguir un nuevo token nativo. La mayoría de blockchains y frameworks Web3 dependen de sistemas criptoeconómicos que comprenden incentivos y penalizaciones para mantener la seguridad del protocolo y disuadir a actores maliciosos.

\ Sin embargo, desplegar una nueva aplicación Web3 como solución de "rollup" o "Capa Dos" ha sido común en los últimos años. Ya sea implementado como un rollup en Ethereum, una parachain en Polkadot, o una subred en Avalanche, el objetivo principal es aprovechar la sólida seguridad económica de la red principal, utilizando su sustancial grupo de validadores y garantías de seguridad.

Los Obstáculos: Justificación para un Token Separado

Actualmente, el desafío técnico de construir una blockchain se ha mitigado significativamente gracias a la disponibilidad de numerosos SDKs y frameworks. Herramientas como Polkadot SDK y Cosmos SDK permiten a los desarrolladores utilizar plantillas y lanzar rápidamente una red funcional, completa con todas las características estándar que se esperarían de cualquier protocolo Web3 estándar.

\ A pesar de estos avances, permanece una barrera importante: identidad, es decir, asegurar que tengamos alguna apariencia de resistencia sybil.

\ ==Todavía necesitamos una manera de asegurar que los actores maliciosos no puedan enviar spam o dañar completamente nuestra red, que es una de las principales razones por las que existen aspectos económicos de sistemas criptoeconómicos como Proof of Work o Proof of Stake.==

\ Tokenomics (economía de tokens) se convierte entonces en una preocupación subsiguiente: si el modelo de token de un proyecto es defectuoso o mal concebido, puede socavar todo el esfuerzo, independientemente de la calidad de la tecnología subyacente.

\ La necesidad de diseñar y asegurar una red criptoeconómica completamente separada presenta un obstáculo considerable para desarrolladores y startups cuya misión principal es construir una aplicación o infraestructura superior y más resiliente, no gestionar una política monetaria.

\ Afortunadamente, el panorama está evolucionando, proporcionando una solución a esta complejidad.

La Solución: Utilizando el Token de la Red "Padre"

Si un nuevo protocolo se construye sobre una red existente y se despliega como un rollup/Capa Dos, deberían, inherentemente, heredar su seguridad de la red padre.

\ Esto plantea una pregunta crítica: ¿por qué no simplemente usar el token nativo de la red padre para todas las operaciones? Todo ya está configurado; solo necesitamos asegurarnos de que podemos realizar controles y equilibrios de manera segura al transferir hacia y desde la red padre. ==En el futuro, podría ser posible lanzar un rollup sin un token en absoluto, si resolvemos el problema Sybil, y asumiendo que tenemos una red padre que proporciona seguridad para nuestro rollup/servicio.==

\ Polkadot permite el lanzamiento de una parachain "sin token". La parachain puede usar en su lugar el token de la Capa Uno (como DOT en Polkadot) para facilitar todas las operaciones, incluidas las comisiones por transacción y los mecanismos de seguridad.

\ Este enfoque libera al equipo para concentrarse en ==construir soluciones y lógica de aplicación central==. En otras palabras, te enfocas más en hacer funcionar tu protocolo para que puedas construir tu aplicación/infraestructura resiliente en lugar de estar atascado por la mecánica de tokens.

Un Ejemplo en Vivo: EduChain

Este concepto no es meramente teórico. El equipo de Educación Técnica de la Fundación Web3 (¡del cual soy parte!) ha experimentado con él con EduChain, que sirve como una demostración en vivo de esta configuración sin token. Utiliza el token de la red padre, específicamente el token PAS en la testnet Paseo, como su moneda funcional.

\ La configuración de EduChain opera a través de una transferencia respaldada por reservas utilizando XCM, que funciona de la siguiente manera:

\

• Suministro inicial cero: la cadena comienza con un suministro total cero de su propio token potencial. Para financiar una cuenta de red, se debe iniciar una transferencia cross-chain a través de XCM desde la red padre (Paseo).

• La reserva y la cuenta soberana: La parachain designa una parachain del sistema (como el Paseo Asset Hub) como reserva para el token padre (PAS). Tras la creación de la parachain, se genera automáticamente una cuenta especializada, conocida como cuenta soberana, en la cadena padre exclusivamente para la parachain.

• Transferencia de PAS:

• Cuando un usuario envía PAS desde su cuenta en la cadena padre (Paseo) a la parachain (EduChain), el PAS se deposita en la cuenta soberana de la parachain en la cadena padre, donde funciona como la reserva.

• Simultáneamente, se acuña un nuevo activo local que representa PAS en la parachain y se acredita a la cuenta del usuario allí.

• Cuando un usuario envía este activo local de vuelta a la cadena padre, el activo local se quema en la parachain, y la cantidad correspondiente de PAS se desbloquea y transfiere desde la cuenta soberana de vuelta a la cuenta del beneficiario en la cadena padre.

  \

Este mecanismo XCM asegura que cada unidad de PAS en la parachain esté completamente respaldada 1:1 por PAS real mantenido en una reserva segura en la red padre, eliminando así la necesidad de un token distinto y específico del proyecto.

\ Como nota general, una parachain controla su propia representación local de un activo y podría, en principio, cambiar esos saldos según su propia gobernanza. Sin embargo, Asset Hub — como ubicación de reserva — mantiene la contabilidad canónica respaldada por reservas para ese activo en toda la red, y se espera que las parachains utilicen instrucciones XCM a través de Asset Hub para que esta contabilidad permanezca correcta y consistente.

\ Para detalles completos sobre EduChain y su mecánica operativa, la documentación está disponible en: https://web3educhain.xyz/

Conclusión

Este artículo tenía como objetivo destacar el potencial significativo de delegar las preocupaciones económicas y de seguridad de un rollup o Capa Dos a la propia red padre. Al emplear transferencias XCM respaldadas por reservas, un proyecto puede eludir completamente las dificultades sustanciales asociadas con el lanzamiento de un nuevo protocolo Web3, permitiendo al equipo dedicar todo su esfuerzo a construir una aplicación superior y abordar problemas del mundo real.

\ Las personas interesadas en implementar esta solución pueden explorar el lanzamiento de una parachain en Paseo, así como el repositorio de EduChain para más información:

\

• Tutoriales de Parachain de Cero a Héroe
• Web3 Educhain

\