El equipo de desarrolladores de NEAR realizó, probablemente, una de las actualizaciones técnicamente más complejas y, al mismo tiempo, más discretas en la historia de las blockchains. En plena actividad activa de la red principal, reemplazaron por completo el motor de ejecución de contratos inteligentes, y la gran mayoría de los usuarios ni siquiera lo notaron. Esto no es solo un cambio de versión, sino un profundo trabajo de ingeniería que incluyó pruebas de estrés con contratos "bomba" y la mitigación del riesgo de una posible división de la red.
Por qué NearVM se convirtió en un "impuesto"
Durante mucho tiempo, NEAR utilizó su propia máquina virtual, NearVM, construida sobre un fork del motor Wasmer. Como explicó Vadim, exdesarrollador del núcleo de NEAR, este compilador "privado" era una especie de impuesto para el equipo. Cada actualización de Rust, cada nueva función de seguridad recaía exclusivamente sobre los hombros del equipo interno, que debía sincronizar y parchear el código manualmente. El proyecto incluso tuvo suerte una vez: se desvió accidentalmente del Wasmer original justo antes de que se descubriera una vulnerabilidad crítica en este último.
Estandarización y aceleración cuádruple
La elección recayó en Wasmtime, un estándar de la industria respaldado por la alianza Bytecode Alliance. Para demostrar la seguridad de la transición, los nodos de la red ejecutaron en paralelo tráfico real a través de ambas máquinas virtuales, verificando cada resultado. Los resultados fueron impresionantes: los resultados coincidieron en un 99,998%, y la discrepancia en las comisiones fue inferior al 0,002%. Además, la velocidad de ejecución aumentó aproximadamente cuatro veces.
Zona prohibida: el problema del consenso
Sin embargo, la principal dificultad no residía en el rendimiento, sino en el consenso. En la red NEAR, la compilación de un contrato ocurre dentro de un bloque de solo 600 milisegundos de duración. El compilador optimizador no tiene un límite de tiempo superior, lo que abría la puerta a un ataque: un contrato de 128 KB que tardara unos 7 segundos en compilarse podría "fallar" el bloque y ralentizar toda la red.
Aparentemente, la solución obvia (establecer un límite de tiempo estricto para la compilación) resultó ser una zona prohibida. Como explicó Vadim, diferentes validadores dedican diferentes tiempos a la compilación. Si se estableciera un límite, algunos nodos aceptarían el contrato y otros lo rechazarían, lo que provocaría una división de la red debido únicamente a la configuración del compilador. El consenso requiere una previsibilidad total, incluso a nivel del tiempo de compilación.
Solución elegante: Winch
En lugar de un límite estricto, el equipo implementó Winch, un backend de Wasmtime de una sola pasada. Después de perfeccionar las funciones faltantes, 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 se trasladó a un tipo separado de procesadores, no vinculado a los nodos ejecutores.
Opinión del analista: Esta actualización es un brillante ejemplo de cómo debería ser una infraestructura madura. NEAR no solo mejoró la seguridad y el rendimiento, sino que también resolvió un problema fundamental de determinismo en condiciones de hardware heterogéneo de los validadores. Para el mercado, esto es una señal: el equipo es capaz de realizar operaciones técnicas extremadamente complejas sin perjudicar la experiencia del usuario, lo que fortalece la confianza en el protocolo a largo plazo.