Hoy seguimos hablando de Sonic, un proyecto que pone vino viejo en botellas nuevas que ha tenido bastante popularidad en los últimos dos días porque mañana habrá un TGE (Token Generation Event) y se darán airdrops. Sonic es el L2 de Sol. ¿Todos se sorprenden de que un SOL tan rápido todavía necesite L2? ¿No es este el punto caliente que necesita el círculo monetario?
Entonces, ¿por qué SOL necesita L2?
A medida que las actividades de dAPP y DeFi en Solana crecen más rápido, las transacciones diarias en cadena superaron los 200 millones en enero de 2024, y algunos analistas estiman de manera conservadora que el volumen de transacciones superará los 4 mil millones en 2026.
Bajo esta presión previsible, el TPS de Solana ronda los 2500-4000, y el tiempo de ping promedio del clúster de Solana fluctúa entre 6 y 80 segundos. Cuando el TPS se satura cada vez más o incluso supera los 4000, la tasa de éxito de las transacciones de Solana solo alcanza del 70% al 85; %.
Además de la latencia física y las fluctuaciones de red causadas por las condiciones de la red, la razón principal está claramente relacionada con el aumento constante de la saturación de TPS. Según la tendencia de crecimiento de Solana, se prevé que el valor de TPS alcance entre 10,000 y decenas de miles en los próximos años, lo que conducirá a problemas de rendimiento más evidentes.
Lo anterior es la respuesta proporcionada por el libro blanco de Sonic, mientras que aquí añado un poco más:
1. En el informe de Messari sobre L2 de Ethereum en los primeros dos días, se mencionó que la capa 1 actual es más adecuada para la liquidación segura, siendo mejor colocar las aplicaciones en L2.
2. Sonic actualmente se centra en ser una cadena de juegos, destacando juegos de cadena completa. Si realmente hay 100,000 o un millón de jugadores en línea, y si los datos son de cadena completa, entonces varios miles o decenas de miles de TPS realmente no podrán soportarlo, por lo que se necesita un L2 más rápido y barato.
Uno. Introducción
Sonic es la primera cadena SVM atómica (lo que significa interoperabilidad atómica, es decir, cuentas y programas que interactúan con sol), y la capa L2 más rápida de Solana. Sonic se basa en el primer marco de escalabilidad concurrente HyperGrid de Solana. A través del intérprete de HyperGrid, se pueden desplegar fácilmente dApps desde cadenas EVM a Solana, por lo que es compatible tanto con EVM como con SOL.
Sonic ofrece en cadena primitivos de juego nativos y tipos de datos escalables basados en el marco ECS. El sandbox del motor de juego proporciona herramientas útiles para ayudar a los desarrolladores a construir la lógica del negocio en la cadena.
Dos. Marco ECS de Rush
Rush es un marco de sistema de entidades-componente-sistema (Entity-Component-System, ECS) completamente construido en Rust, cuyo único objetivo es: reducir al mínimo la complejidad de la integración de la tecnología blockchain con las herramientas que los desarrolladores conocen (como SDK y API de motores de juego) a través de la adopción de experiencias de desarrollo verificadas y técnicas de abstracción.
Rush vislumbra un futuro en el que cualquier juego que ya se haya construido o que se esté construyendo, pueda ser fácilmente transformado en un juego de cadena completa (Fully-Onchain Game) o un mundo autónomo (Autonomous World) a través de Rush y su stack tecnológico de desarrollo de juegos preferido.
Cómo funciona Rush
Por lo general, los desarrolladores de juegos utilizan motores de juego para crear juegos.
Con la ayuda del motor de juego, la complejidad de la lógica subyacente se reduce drásticamente, permitiendo a los desarrolladores concentrarse en el diseño y la mecánica del juego, mientras que la complejidad es manejada por el motor de juego.
Por otro lado, la implementación de juegos de cadena completa (FOCG) y mundos autónomos (AW) debe depender de un almacenamiento de datos descentralizado, como la blockchain.
Esta característica descentralizada hace que la persistencia de los datos sea mucho más robusta que la de un único repositorio de datos, pero también conlleva costos adicionales.
Problemas que enfrentan los desarrolladores
Para implementar FOCG o AW, los desarrolladores de juegos necesitan dominar la tecnología de blockchain de pila completa o contratar expertos en blockchain.
Tanto si se trata de aprender como de contratar, esto requiere una gran cantidad de recursos y a menudo representa un gran obstáculo para los desarrolladores de juegos en su camino hacia juegos de cadena completa o mundos autónomos.
Rush nació precisamente para abordar este problema.
Se logra a través de experiencias de desarrollo eficientes y verificadas, como:
- Configuración declarativa
- Entidad-Componente-Sistema (Entity-Component-System, ECS)
- Generación de código
Lo que simplifica drásticamente la complejidad.
Tres. Marco de HyperGrid
El protocolo HyperGrid es un marco de extensión y orquestación de Rollup, diseñado para apoyar a los operadores de Rollup en el ecosistema SVM. Logra un potencial de rendimiento de transacciones ilimitadas mediante la compresión de estados y la tolerancia a fallos bizantinos (Byzantine Fault Tolerance, BFT). Esto se logra mediante la escalabilidad horizontal entre múltiples cuadrículas (Grids), como se muestra en Sonic (una cuadrícula enfocada en juegos), cuyas transacciones finalmente se liquidan en Solana.
3.1 Resumen de la arquitectura
Resumen de la arquitectura multicanal de HyperGrid: cuadrículas semi-autónomas que logran consenso y finalización a través de Solana.
La arquitectura de HyperGrid se basa en un modelo de múltiples cuadrículas (multi-grid), donde cada cuadrícula opera de manera semi-autónoma mientras logra consenso y finalización a través de la red principal de Solana.
3.2 Arquitectura del sistema HyperGrid
Componentes clave
1. Capa base de Solana:
- La base del sistema HyperGrid, proporcionando consenso final y finalización de datos.
2. Red de estado compartido de HyperGrid (HSSN):
- El núcleo del sistema, que opera a través de todas las cuadrículas.
- Incluye múltiples validadores (Validator 1 a Validator N).
- Compartir estado entre la cuadrícula y la capa base de Solana.
- Gestionar pruebas de conocimiento cero (ZK Proofs) en lote para liquidaciones.
3. Estructura de cuadrícula (tomando Grid 1 y Grid 2 como ejemplos):
- Cada cuadrícula representa un ecosistema semi-autónomo que puede estar dedicado a aplicaciones específicas (como diferentes juegos).
- Los componentes de cada cuadrícula incluyen:
- ZK coprocessor: Maneja operaciones específicas de la cuadrícula y pruebas de Merkle.
- Tiempo de ejecución SVM: Ejecuta operaciones de cuadrícula en la máquina virtual de Solana.
- Motor de Gas Sonic: Gestiona recursos de computación.
- Generador de árboles Merkle concurrente: maneja eficientemente las transiciones de estado.
4. Interacción del usuario:
- Los usuarios pueden interactuar de forma independiente con cada cuadrícula.
- Las transacciones (incluidas las transacciones SVM y EVM) circulan entre los usuarios y el tiempo de ejecución de la cuadrícula correspondiente.
- La respuesta de la transacción se devuelve al usuario.
3.2 Flujo de datos
Interoperabilidad y compartición de estado:
- Compartición de estado bidireccional entre la capa base de Solana y HSSN.
- HSSN compartirá el estado entre las cuadrículas.
- El intercambio de estados también puede ocurrir entre diferentes cuadrículas.
3.4 Prueba ZK:
1. Las transacciones se comprimen y agregan en un árbol Merkle.
2. Para cada bloque, se presenta el valor hash del estado raíz correspondiente.
3. Prueba de validez (Validity Proof) calculada en la cuadrícula.
4. HSSN utiliza pruebas ZK para liquidar y enviarlas a la capa base de Solana.
Cuatro. Comunicación entre cuadrículas y redes
La arquitectura de la red de HyperGrid: la relación entre la red de estado compartido, las instancias de cuadrícula y la capa base de Solana, proporciona soporte para el despliegue de dApp escalables.
Flujo de datos de la red de estado compartido de HyperGrid
El marco de HyperGrid está diseñado para soportar una amplia gama de redes específicas de aplicaciones o aplicaciones descentralizadas (dApp), prestando especial atención a las aplicaciones con alta demanda dentro de su ecosistema, como juegos, DeFi, agentes de IA, etc.
Los objetivos de esta arquitectura incluyen:
1. Aliviar la presión de rendimiento en la capa base de Solana.
2. Minimizar los conflictos y la competencia de rendimiento entre la capa base y varias dApp específicas debido a la competencia por el espacio de bloque.
Características clave
1. Flexibilidad, proporcionando opciones a los creadores de redes de cuadrículas:
- Los desarrolladores pueden elegir:
- Usar la red pública de HyperGrid.
- Escalabilidad horizontal para crear redes exclusivas dedicadas a necesidades específicas.
2. Optimización de rendimiento y costos:
- La elección entre red pública y red exclusiva depende de la evaluación de los desarrolladores sobre los requisitos de rendimiento y los costos asociados.
3. Independencia de la red:
- Los desarrolladores pueden desactivar su red exclusiva en cualquier momento sin afectar a otras redes dentro del ecosistema.
Marco de operación
1. Validación:
- Cada red maneja de forma autónoma la validación de sus transacciones y cambios de estado.
2. Registro:
- Cada red mantiene de manera independiente su registro de transacciones y cambios de estado.
3. Recuperación de datos:
- El proceso de recuperación de datos se ejecuta de forma independiente en cada red.
Cinco. Interoperabilidad con Solana
5.1 Leer datos desde Solana hacia HyperGrid
La imagen anterior ilustra el siguiente proceso al ejecutar la sincronización del estado desde Solana hacia la cuadrícula en HyperGrid (como Sonic).
Carga inicial: Cargar programas existentes desde el almacenamiento a la caché de HyperGrid.
Los usuarios envían solicitudes de lectura de programas específicos a Sonic RPC de HyperGrid.
El programa de sincronización verifica si el programa solicitado existe en la caché, pero no lo encuentra.
El programa de sincronización envía solicitudes de programa a la capa base de Solana RPC.
La capa base de Solana responde utilizando datos del programa.
El programa de sincronización recibe la respuesta y utiliza los nuevos datos del programa para actualizar la caché de HyperGrid.
El programa de sincronización envía la respuesta de lectura de vuelta a Sonic RPC.
Sonic RPC reenvía la respuesta de lectura al usuario.
5.2 Sincronización de actualizaciones de vuelta a la capa base de Solana
La imagen anterior ilustra el siguiente proceso al ejecutar la sincronización del estado desde la cuadrícula en HyperGrid (como Sonic) de regreso a Solana.
Carga inicial: Cargar programas existentes desde el almacenamiento a la caché de HyperGrid.
Los usuarios envían solicitudes de escritura de programas específicos a Sonic RPC de HyperGrid.
El programa de sincronización verifica si el programa solicitado existe en la caché, pero no lo encuentra.
El programa de sincronización envía solicitudes para bloquear el programa en la capa base de Solana.
La capa base de Solana RPC bloquea la solicitud del programa.
La capa base de Solana responde utilizando datos del programa.
El programa de sincronización recibe la respuesta y utiliza los nuevos datos del programa para actualizar la caché de HyperGrid.
El programa de sincronización envía solicitudes para liberar el bloqueo y escribe los datos de actualización del programa en la capa base de Solana.
La capa base de Solana RPC libera el bloqueo y escribe los datos actualizados.
El programa de sincronización envía la respuesta de escritura de vuelta a Sonic RPC.
Sonic RPC reenvía la respuesta de escritura al usuario.
Seis. Red de estado compartido HyperGrid (HSSN)
La red de estado compartido HyperGrid (HSSN) es un componente clave dentro del ecosistema Grid. Actúa como capa de consenso, centro de comunicación y clúster de gestión de estado, facilitando la interacción entre la cuadrícula y la capa base de Solana. Esta red gestiona todo el estado de las comunicaciones, incluyendo la sincronización periódica de los datos de bloques desde los Rollups de la cuadrícula a la capa base de Solana.
Componentes y funciones principales
La arquitectura HSSN: construida sobre el marco de Cosmos, garantiza la fiabilidad y seguridad de la comunicación entre cadenas.
Estructura de datos: Gestiona el estado entre la cuadrícula y la capa base de Solana, incluyendo:
- Registro de la red eléctrica
- Fuente de datos de comunicación
- Control de versiones
- Leer/escribir estado
- Ampliación de los campos de datos de las cuentas: Mejora los campos de datos de las cuentas nativas de Solana para acomodar nuevos campos de gestión de HSSN, asegurando la sincronización con el estado de las cuentas de la cuadrícula.
- RPC de cuadrícula reconstruido: permite la comunicación directa entre cuadrículas y HSSN, facilitando la interoperabilidad dentro del ecosistema.
Mecanismo de carga y distribución de GAS: los usuarios pagan tarifas de gas por ciertas solicitudes de la red, una cuadrícula dedicada (Sonic Grid) ejecuta programas de cálculo de gas, gestionando centralmente el gas del ecosistema de la red.
Estado de la financiación del proyecto
Sonic completó una ronda de financiación de 12 millones de dólares en la serie A, liderada por Bitkraft Ventures, con la participación de Galaxy Interactive, BigBrain Holdings y otras empresas, y actualmente está valorada en 120 millones de dólares.
TGE:
La oferta total de SONIC es de 2.4 mil millones de tokens, de los cuales el 57% se asigna a la comunidad, que incluye desarrollo comunitario y ecológico (30%), reclamación inicial (7%) y recompensas de HyperGrid (20%). El TGE está programado para el 7 de enero de 2025, con un volumen de circulación inicial del 15% del total. SONIC se distribuirá en 6 años, momento en el cual todos los SONIC estarán completamente en circulación, la mayoría de los cuales se asignarán a la comunidad. Durante los primeros 12-18 meses después del lanzamiento, no se desbloqueará ningún token para el equipo y los inversores, y los tokens bloqueados no se podrán apostar.
Finalmente, resumiendo este proyecto, SOL ha comenzado a lanzar L2, por lo que en realidad, en las cadenas públicas rápidas, debería haber una demanda de L2. Siguiendo esta lógica, la arquitectura multicanal de avax realmente muestra que es útil, y el L2 de SOL podría surgir en un momento.
