El equipo de NEAR Protocol llevó a cabo una de las operaciones de ingeniería más arriesgadas en la historia de blockchain: la sustitución del motor de contratos inteligentes se realizó en la red principal en funcionamiento, y la gran mayoría de los usuarios ni siquiera lo notó. Como explicó Vadim, exdesarrollador del núcleo de NEAR, la discreción era el objetivo principal de esta actualización.

Durante años, NEAR utilizó su propio motor bifurcado de Wasmer: NearVM. Este "compilador privado", como lo llamó Vadim, era una especie de "impuesto" al desarrollo: cada actualización del lenguaje Rust, cada nueva función de seguridad recaía exclusivamente sobre los hombros del equipo interno. El proyecto tuvo suerte una vez: dejó de sincronizarse con el Wasmer original justo antes de que se descubriera una vulnerabilidad crítica en este último. En esencia, NEAR estaba sentado sobre un barril de pólvora.

El reemplazo por Wasmtime, el estándar de la industria de Bytecode Alliance, era inevitable. Para confirmar la seguridad de la migración, los nodos de la red ejecutaron en paralelo tráfico real a través de ambas máquinas virtuales y compararon cada resultado. Los resultados son impresionantes: el resultado de la ejecución coincidió por completo, y la discrepancia en las comisiones fue inferior al 0,002%. Además, la ejecución de los contratos se aceleró aproximadamente cuatro veces.

La solución prohibida y la jugada de ingeniería

La principal dificultad no residía en la velocidad de 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 un ataque. El equipo creó un contrato de prueba de 128 KB cuya compilación tomaba unos 7 segundos, suficiente para "fallar" el bloque y ralentizar toda la red.

La solución obvia, establecer un límite de tiempo para la compilación, resultó ser prohibida. Como explicó Vadim, diferentes validadores tardan tiempos distintos en compilar, por lo que un contrato límite sería aceptado por unos nodos y rechazado por otros. La consecuencia sería una división de la red debido únicamente a la configuración del compilador. El consenso requiere una previsibilidad total, incluso del tiempo de compilación.

El equipo encontró otra salida. Implementaron Winch, un backend de una sola pasada de Wasmtime, y le agregaron las funciones faltantes. Como resultado, el "peor caso de compilación" se redujo de 7,6 segundos a 36 milisegundos. El trabajo fuera de la cadena de bloques proporcionó un "lujo inaccesible para el protocolo": la compilación puede trasladarse a un tipo separado de procesadores, no vinculado a los nodos ejecutores.

El lanzamiento de Nearcore 2.12 trasladó el entorno de ejecución de NEAR de NearVM a Wasmtime. Como destacó el desarrollador Anton, para los desarrolladores y usuarios nada cambió, y ese es el objetivo: "El equipo cerró una deuda técnica crítica sin romper nada".

Comentario del analista: Esta operación es un brillante ejemplo de la madurez de la cultura de ingeniería de NEAR. Reemplazar la VM bajo la carga de la red principal sin un solo fallo es un nivel al que solo unos pocos pueden acceder. La aceleración de 4 veces y la eliminación del vector de ataque al consenso no son solo una actualización, sino un fortalecimiento fundamental de la seguridad y el rendimiento de la red.