El equipo de NEAR Protocol llevó a cabo una operación técnicamente muy compleja, reemplazando el motor de ejecución de todos los contratos inteligentes directamente durante el funcionamiento de la red principal. Los usuarios y desarrolladores, según el diseño de los ingenieros, no debían notar ningún cambio, y lo lograron.

Por qué el antiguo motor se convirtió en un "impuesto"

Durante años, NEAR dependió de NearVM, una bifurcación del popular motor Wasmer. El problema era que esta bifurcación era mantenida exclusivamente por el propio proyecto. Cada actualización del lenguaje Rust, cada nueva función de seguridad recaía como una carga sobre el equipo de NEAR. Esto era ineficiente y arriesgado. El proyecto tuvo una vez suerte: no se sincronizó con el Wasmer original justo antes de que se descubriera una vulnerabilidad crítica en este último. Tras evitar accidentalmente una catástrofe, el equipo decidió que esto no podía continuar así.

Transición a Wasmtime: cómo fue

El nuevo estándar fue Wasmtime, un motor industrial bajo el paraguas de Bytecode Alliance. Pero no se podía simplemente "accionar un interruptor". Para demostrar la corrección y seguridad de la transición, los validadores de la red ejecutaron en paralelo todo el tráfico real a través de ambas máquinas virtuales, verificando cada resultado. La coincidencia fue absoluta: la diferencia en las comisiones fue inferior al 0,002%, y la ejecución de los contratos se aceleró cuatro veces.

La solución "prohibida" y las bombas para el compilador

El principal desafío de ingeniería no estaba en la ejecución, sino en la compilación. 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 ataques DoS. El equipo creó un contrato "bomba" de 128 KB, cuya compilación tomaba 7 segundos, suficiente para "fallar" el bloque y ralentizar toda la red.

La solución obvia —introducir un límite de tiempo estricto para la compilación— resultó ser prohibida. Diferentes validadores gastan diferentes tiempos en la compilación, y un umbral único habría llevado a una división de la red: algunos nodos aceptarían el contrato, otros lo rechazarían.

Una salida elegante y resultados

La solución se encontró en la integración de Winch, un backend de un solo paso de Wasmtime. Al agregar las funciones faltantes, el equipo redujo el "peor caso de compilación" de 7,6 segundos a 36 milisegundos. El trabajo fuera de la cadena de bloques proporcionó un "lujo no disponible para el protocolo": la compilación se trasladó a un tipo separado de procesadores, no vinculado a los nodos de ejecución.

El lanzamiento de Nearcore 2.12 trasladó el entorno de ejecución de NEAR de NearVM a Wasmtime. Para los desarrolladores y usuarios, nada cambió: el equipo cerró una deuda técnica crítica sin romper nada. No es una noticia que llegue a los titulares, pero son este tipo de actualizaciones las que hacen que la infraestructura sea verdaderamente confiable.

Comentario del analista: Reemplazar una VM bajo carga es la máxima expresión de la ingeniería. NEAR no solo resolvió un problema de seguridad y rendimiento, sino que también demostró la madurez de su base de código. Para inversores y desarrolladores, es una señal de que el equipo es capaz de realizar maniobras técnicas complejas sin perjudicar la red.