El equipo de desarrolladores de NEAR llevó a cabo, probablemente, una de las operaciones de ingeniería más impresionantes del año: directamente durante el funcionamiento de la red principal, bajo carga real, reemplazaron el motor de ejecución de contratos inteligentes. Y lo hicieron prácticamente de manera imperceptible para los usuarios. Esto no es solo una actualización, es un cambio de fundamento que permaneció entre bastidores.

¿Por qué era necesario?

Durante años, NEAR dependió de su propia implementación de la máquina virtual NearVM, construida sobre un fork del motor Wasmer. Este compilador "privado", según un exdesarrollador del núcleo de la red, era un verdadero "impuesto" para el proyecto. Cada actualización del lenguaje Rust, cada nueva función de seguridad recaía sobre los hombros de un pequeño equipo. Incluso, en una ocasión, esto llevó a que el proyecto evitara accidentalmente una vulnerabilidad crítica en el Wasmer original, simplemente por haber dejado de sincronizarse con él un día antes de que se descubriera el error. Esto no podía continuar así por mucho tiempo.

Wasmtime: el estándar de la industria al servicio de la seguridad

La elección recayó en Wasmtime, la implementación de referencia de WebAssembly respaldada por la alianza Bytecode Alliance. Esto no es solo un cambio de "tuerca", es una transición hacia un estándar que es desarrollado por toda la comunidad. La prueba de seguridad se realizó 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. La discrepancia en las comisiones fue inferior al 0,002%, y la velocidad de ejecución aumentó aproximadamente cuatro veces.

La solución prohibida y la "bomba" de ralentización

El principal enigma de ingeniería no residía 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 solo 600 milisegundos de duración. El problema es que el compilador optimizador no tiene un límite superior de tiempo de ejecución. El equipo creó un contrato de prueba de 128 KB, cuya compilación tomaba alrededor de 7 segundos, suficiente para "fallar" el bloque y ralentizar toda la red.

La solución aparentemente simple —establecer un límite de tiempo para la compilación— resultó estar prohibida. Como explicaron los desarrolladores, diferentes validadores dedican tiempos distintos a la compilación. Un contrato límite sería aceptado por unos nodos y rechazado por otros. El resultado: una división de la red debido a una sola configuración del compilador. El consenso requiere una previsibilidad total, incluso del tiempo de compilación.

La salida elegante: Winch y la externalización de la compilación

En lugar de usar la fuerza bruta, el equipo aplicó elegancia ingenieril. Implementaron Winch, un backend de un solo paso de Wasmtime, y le añadieron las funciones faltantes. Como resultado, el "peor caso de compilación" se redujo de 7,6 segundos a 36 milisegundos. Además, la compilación se trasladó a un tipo separado de procesadores, no vinculado a los nodos de ejecución. Como señaló Vadim, trabajar fuera de la cadena de bloques proporciona un "lujo inaccesible para el protocolo".

Veredicto del analista: Esta actualización es un brillante ejemplo de cómo debería ser una infraestructura madura. NEAR no solo cambió el motor, sino que resolvió un problema fundamental de seguridad y rendimiento sin llamar la atención ni generar revuelo. Para mí, esto es una señal de la alta calidad de la cultura de ingeniería del proyecto, lo cual, a largo plazo, es mucho más importante que las grandes declaraciones de marketing.