Erik Zhang lanza Neo N3 v3.10.2 y corrige una omisión en la verificación de testigos multisig
Puntos clave
- •Neo publicó Neo N3 v3.10.2 el 23 de octubre, una versión de seguridad escrita por el cofundador Erik Zhang que contiene una única corrección lógica y ninguna función nueva.
- •El parche elimina una omisión en la verificación de testigos causada por una validación inconsistente de claves públicas entre las sobrecargas de contratos multisignature, que anteriormente permitía que scripts malformados pasaran por una ruta de validación y fallaran en otra.
- •Todas las rutas de código de validación ahora obligan a la decodificación criptográfica completa de las claves públicas antes de clasificar un script como contrato multisig válido, mediante una pequeña edición en Helper.cs.
- •El commit agrega dos pruebas nuevas y actualiza una existente para confirmar que los scripts con claves públicas inválidas son rechazados por todas las rutas de validación, incluyendo un caso de transacción completa con testigos hash no coincidentes.
- •No se ha reportado explotación confirmada en la MainNet de Neo N3, y la corrección solo surte efecto en los nodos que ejecuten la versión parcheada, lo que hace que la adopción por parte de los operadores sea el siguiente paso clave.

Neo ha lanzado Neo N3 v3.10.2, un parche de seguridad dirigido que cierra una omisión en la verificación de testigos que anteriormente permitía que scripts multisignature malformados pasaran por una ruta de validación mientras eran detectados por otra. Para los usuarios comunes, la corrección elimina una vía por la cual una transacción inválida podía parecer válida para parte del software del nodo.
La versión, escrita por el cofundador de Neo Erik Zhang, fue publicada el 23 de octubre. Contiene una única corrección lógica en la lógica de validación de contratos multisignature de Neo N3, y ninguna función nueva.
Qué corrige el parche
Cuando una transacción se envía a la red Neo N3, el protocolo verifica que las firmas adjuntas sean válidas y provengan de las partes correctas. Esos datos de autorización —las firmas y las verificaciones adjuntas a una transacción— son lo que el protocolo llama su testigo (witness), y es la capa que este parche refuerza. Para los contratos multisignature, que requieren un número mínimo de firmantes autorizados para aprobar una transacción y se usan comúnmente cuando varias partes comparten el control de los mismos fondos, esa verificación incluye comprobar que cada clave pública listada en el script del contrato sea criptográficamente válida.
El parche cierra una brecha en cómo se aplicaba esa verificación. La lógica de validación multisig de Neo N3 incluía múltiples rutas de código para inspeccionar un script multisig. Una de esas rutas decodificaba completamente cada clave pública, un proceso que rechazaba de inmediato cualquier clave que no fuera un punto válido en la curva elíptica. Una segunda ruta solo verificaba la forma estructural del script —las longitudes de bytes correctas y el número correcto de claves— sin realizar la decodificación criptográfica. Por lo tanto, un script con una clave pública malformada podía pasar la segunda ruta y fallar la primera, dejando a las dos rutas en desacuerdo sobre si el script era válido. Ese tipo de desacuerdo contradice una propiedad básica que se espera de la validación en blockchain: el mismo script debería producir el mismo veredicto sin importar qué ruta de código lo inspeccione.
La inconsistencia no era desconocida. El comportamiento estaba documentado en la propia suite de pruebas de Neo desde 2024, cuando la desarrolladora de Neo SPCC Anna Shaleva portó nuevo código de verificación de testigos de NeoGo al nodo de referencia en C#. Una prueba añadida en ese pull request señalaba la sobrecarga básica de IsMultiSigContract comounlucky" por omitir la decodificación de claves, pero trataba el resultado como comportamiento esperado y no como un defecto. Las dos implementaciones en juego allí —el nodo de referencia en C# y NeoGo— subrayan por qué importa el comportamiento uniforme: en una red mantenida en más de una implementación de nodo, cada una debe fallar de la misma manera ante la misma transacción.
La corrección resuelve la discrepancia. Todas las rutas de la lógica de validación ahora obligan a la decodificación completa de las claves antes de clasificar un script como un contrato multisig válido.
Corrección y cobertura de pruebas
El cambio es una pequeña edición en src/Neo/SmartContract/Helper.cs. La corrección decodifica la clave cada vez, de modo que cada ruta que inspecciona un script multisig ahora ejecuta la misma verificación.
El commit agrega dos pruebas nuevas y actualiza una existente. La primera nueva prueba alimenta a las tres rutas de validación con un script multisig con una clave pública rota y confirma que cada una la rechaza. La segunda construye una transacción completa con un testigo multisig roto y confirma que la red la rechaza. Esa prueba se ejecuta dos veces: una con la dirección del firmante coincidiendo con el testigo y otra con una discrepancia, cubriendo el caso de "mismatched witness hashes" señalado en las notas de la versión.
La prueba actualizada, TestIsMultiSigContract_WrongCurve, anteriormente esperaba que la ruta de atajo aceptara scripts con claves inválidas. Ahora espera que las tres rutas las rechacen, fijando el comportamiento corregido en la suite contra regresiones futuras.
Jimmy Liao, desarrollador principal de Neo y fundador de R3E Network, describió la versión en X:
Neo N3 v3.10.2 — security release. Fixes a witness-verification bypass from inconsistent public-key validation between
IsMultiSigContractoverloads. Keys are now validated before multisig classification.
Sin explotación conocida
No se publicó ningún aviso de seguridad formal junto con la versión. Ni las notas de la versión ni el mensaje del commit describen explotación confirmada en la MainNet de Neo N3.
Los operadores de nodos y proveedores de infraestructura que ejecuten Neo N3 deben actualizar a v3.10.2 — al ser una corrección del lado del cliente, su verificación más estricta solo surte efecto en los nodos que realmente ejecuten la versión parcheada, lo que hace que la adopción por parte de los operadores sea el siguiente paso práctico a observar. La versión completa está disponible en GitHub.