R3E Network despliega prototipo de red elástica multi-L2 en la TestNet de Neo N3

R3E Network ha desplegado su prototipo de red elástica neo-n4 en la TestNet de Neo N3, lo que marca la primera implementación en vivo de la arquitectura multi-L2 independiente creada por el desarrollador principal de Neo, Jimmy Liao. Aunque lleva el nombre "neo-n4", el proyecto es independiente del trabajo protocolar canónico de Neo 4 de Erik Zhang: el esfuerzo de Zhang apunta a una evolución de la máquina virtual RISC-V de la capa de ejecución central de Neo, mientras que el neo-n4 de Liao es una capa de escalado L2 construida sobre Neo N3. El proyecto neo-n4 no está afiliado a Neo Global Development, la Neo Foundation ni la organización neo-project, ni ha recibido su respaldo.

Con cinco contratos centrales de liquidación ahora operativos en la TestNet, el proyecto ha superado el repositorio de código exploratorio que Neo News Today (NNT) cubrió en mayo y se ha convertido en un prototipo funcional en cadena. El repositorio ahora abarca las fases 0-6, con contratos en vivo que reemplazan lo que antes existía solo como especificaciones sin desplegar.

Liao, fundador de R3E Network, describió la intención del proyecto el día del despliegue: "Same thesis as Neo X and SpoonOS: Neo N4 isn't about launching a new chain. It's about building chain-native apps on top of N3, application-centric, serving users better in the AI era." La referencia apunta a Neo X, la sidechain de Neo compatible con EVM, y a SpoonOS, un framework de agentes de IA del ecosistema Neo, como expresiones anteriores de la misma tesis centrada en las aplicaciones.

Qué permite el modelo de red elástica

El modelo de red elástica está diseñado para que las aplicaciones se ejecuten en sus propias cadenas dedicadas mientras Neo N3 sirve como capa común de liquidación y seguridad. Por ejemplo, una aplicación de juegos podría ejecutarse en una cadena optimizada para alto rendimiento y baja latencia, mientras que una aplicación DeFi ocupa una cadena separada con garantías de seguridad más estrictas; sin embargo, ambas dependerían del mismo puente para el movimiento de activos del mismo marco de gobernanza. Así, los usuarios y los activos podrían moverse entre estas cadenas sin que cada aplicación tenga que construir su propio puente o infraestructura de seguridad desde cero. El enfoque refleja las arquitecturas multi-rollup que se exploran en Ethereum, adaptadas a la pila protocolar de Neo.

Contratos desplegados en la TestNet

Cinco contratos de liquidación L1 fueron desplegados en la TestNet de Neo N3, cada uno con un rol distinto en la arquitectura de red elástica:

• RollupHub: registro de cadenas, envío de lotes y inclusión forzada.
• SharedBridge: custodia de activos que gestiona depósitos y retiros entre capas.
• GovernanceController: gobernanza basada en consejo con propuestas y mecanismos de timelock.

Dos contratos adicionales se encargan de la verificación de pruebas: ZkVerifier enruta las pruebas, mientras que Sp1Groth16Verifier verifica las atestaciones de comité mediante el emparejamiento Groth16/BN254 de SP1 v6.2.1.

Descripción general de la arquitectura

La arquitectura neo-n4 sigue un diseño de tres niveles adaptado del patrón ZKsync Elastic Chain y reconstruido sobre la propia pila de Neo, combinando el consenso dBFT 2.0, los estándares de tokens NEP-17 y NeoFS para la disponibilidad de datos.

NeoHub se sitúa en la capa base sobre Neo N3 y coordina la liquidación entre múltiples cadenas L2. Cada cadena L2 mantiene su propio entorno de ejecución mientras comparte la infraestructura de puente utilizada para mover activos entre capas. Entre L1 y L2 se encuentra una capa opcional de agregación Gateway que gestiona la agregación de pruebas.

El sistema admite tres rutas de prueba: atestación multisig, rollup optimista con una ventana de fraud-proof y pruebas de validez ZK mediante SP1 RISC-V. Se incluyen siete plantillas de cadenas elásticas—que abarcan casos de uso como DEX, juegos, DeFi, redes sociales, NFT, pagos y empresas—como prototipos de investigación para validación y pruebas.

Resultados de validación

Los despliegues de este tipo en TestNet permiten que un conjunto de contratos se ejecute en un entorno público sin activos de mainnet en juego. Las pruebas previas al despliegue cubrieron 1.475 de 1.478 pruebas—338 pruebas de VM, 55 pruebas de integración y 1.082 pruebas unitarias—alcanzando una cobertura del 99,8%. Las pruebas de humo posteriores al despliegue arrojaron 12 de 12 pruebas aprobadas, con los cinco despliegues de contratos exitosos y seis enlaces entre contratos verificados.

La validación RPC registró 11 de 14 comprobaciones exitosas; las tres fallas restantes fueron problemas de formato de parámetros señalados como no bloqueantes. El estado génesis ya está preparado para la primera cadena L2.\n## Alcance y advertencias

El repositorio ahora contiene 38 proyectos de prueba .NET, 16 bibliotecas centrales fuera de cadena, ocho plugins de nodo, cinco proyectos de contratos L1 con 10 contratos nativos L2, siete herramientas CLI y cuatro fuentes de SDK entre .NET, TypeScript, Rust y Python.

No obstante, el despliegue conlleva advertencias significativas. Ninguna fase de la matriz de estado de implementación está marcada como lista para producción. El repositorio no ha sido sometido a una auditoría de seguridad divulgada, y varios requisitos de producción—incluida la integración de firmantes HSM/KMS y un backend de NeoFS revisado—siguen sin resolverse. Una auditoría de seguridad divulgada es un requisito habitual para el despliegue en producción de infraestructura de este tipo. Las pruebas SP1 reales son opcionales mediante un flujo de trabajo manual, mientras que el CI estándar ejecuta solo comprobaciones rápidas de compatibilidad. Las siete plantillas de cadenas elásticas se describen explícitamente como prototipos de investigación, no como cadenas de producción planificadas.

Perspectivas

El despliegue en TestNet lleva a neo-n4 de una arquitectura teórica a un prototipo operativo, aunque el proyecto sigue firmemente en una fase de investigación y exploración. Desde la cobertura de NNT en mayo, R3E Network ha completado las fases 4-6, añadiendo pruebas de validez NeoVM2/SP1 RISC-V, agregación Gateway y herramientas CLI sobre las fases 0-3 ya existentes.

No se ha revelado un cronograma de despliegue en MainNet, y el trabajo continúa como ingeniería exploratoria independiente de R3E Network. Los indicadores a observar incluyen la resolución de las tres fallas no bloqueantes de formato de parámetros RPC, el paso de las pruebas SP1 reales del flujo manual opcional al CI estándar y si el estado génesis preparado avanza hacia una primera cadena L2 activa en la TestNet; cualquier paso hacia la producción también requeriría la auditoría de seguridad pendiente, la integración de firmantes HSM/KMS y un backend de NeoFS revisado, señalados como no resueltos.

Los resultados completos del despliegue y el repositorio están disponibles en: https://github.com/r3e-network/neo-n4