El equipo de desarrolladores de NEAR llevó a cabo una compleja operación de ingeniería: bajo la carga de la red en vivo, se reemplazó el motor de ejecución de todos los contratos inteligentes. Los usuarios no notaron nada, y la red no solo no perdió rendimiento, sino que obtuvo un aumento significativo en velocidad.
Se trata del reemplazo de la máquina virtual NearVM, un fork del motor Wasmer que el proyecto utilizó durante muchos años. Como explicó Vadim, exdesarrollador del núcleo de NEAR, NearVM era un "compilador privado": todas las actualizaciones del lenguaje Rust, correcciones de seguridad y nuevas funciones recaían exclusivamente sobre los hombros del equipo del proyecto. Esto creaba un grave "impuesto" de mantenimiento y, lo que es crítico, el riesgo de pasar por alto una vulnerabilidad. Según el experto, en una ocasión el proyecto tuvo suerte: evitó accidentalmente una brecha crítica en el Wasmer original simplemente por no haber sincronizado a tiempo con el lanzamiento.
El nuevo fundamento se convirtió en Wasmtime, un estándar de la industria respaldado por la alianza Bytecode Alliance. La transición se preparó con precisión quirúrgica: los nodos de la red ejecutaron en paralelo tráfico real a través de ambas máquinas virtuales y verificaron cada resultado. Los resultados de las pruebas son impresionantes: los resultados de ejecución coincidieron por completo, la discrepancia en las comisiones fue inferior al 0,002%, y la velocidad de ejecución en sí aumentó aproximadamente cuatro veces.
El principal dolor de cabeza: el problema de la solución "prohibida"
Sin embargo, la dificultad clave no residía en la ejecución en sí, sino en la compilación de los contratos. En la red NEAR, el despliegue de un contrato se compila directamente dentro de un bloque de 600 milisegundos de duración. El compilador optimizador no tiene un límite superior de tiempo de ejecución, lo que abría la puerta a un ataque. El equipo creó un contrato de prueba de 128 KB, cuya compilación tomaba unos 7 segundos; esto era suficiente para "fallar" el bloque y ralentizar toda la red.
Parecía una solución obvia establecer un límite de tiempo estricto para la compilación. Pero Vadim explica que este era un camino prohibido. Diferentes validadores dedican diferentes tiempos a la compilación, y un contrato límite sería aceptado por unos nodos y rechazado por otros. El resultado sería una división de la red (fork) debido a una única configuración del compilador. El consenso requiere una previsibilidad total, incluso a nivel del tiempo de compilación.
Una salida elegante: Winch y la externalización de la compilación
En lugar de una limitación arriesgada, el equipo encontró otra solución. Implementaron Winch, un backend de un solo paso de Wasmtime, y le añadieron las funciones faltantes. Esto permitió reducir drásticamente el "peor caso de compilación": de 7,6 segundos a solo 36 milisegundos. Además, la arquitectura de Wasmtime permite externalizar la compilación a un tipo separado de procesadores no vinculados a los nodos de ejecución. Como señaló Vadim, "trabajar fuera de la cadena de bloques otorga un lujo inaccesible para el protocolo".
El lanzamiento de Nearcore 2.12, anunciado por el desarrollador Anton, trasladó el entorno de ejecución de NEAR de NearVM a Wasmtime. Este es un trabajo que no aparece en los titulares de los medios, pero tiene una importancia colosal para la sostenibilidad a largo plazo de la red. El equipo cerró una deuda técnica crítica sin romper nada ni cambiar la experiencia del usuario.
Opinión del experto: Esta actualización es un brillante ejemplo de una cultura de ingeniería madura en el espacio cripto. NEAR no solo aceleró la red y mejoró su seguridad al migrar a un estándar compatible. Mucho más importante es que el equipo resolvió una tarea de consenso extremadamente compleja de manera elegante, sin compromisos. Externalizar la compilación fuera de la ruta crítica de ejecución es una decisión arquitectónica que reduce la carga sobre los validadores y aumenta la resistencia de la red a los ataques. Para los tenedores de tokens y los desarrolladores, esto es una señal: el protocolo invierte seriamente en su infraestructura, permaneciendo invisible para el usuario final. Son precisamente estas actualizaciones "invisibles" las que crean la base para la adopción masiva.