Por Canuto  

NEAR quiere aplicar verificación formal asistida por IA a su protocolo y contratos inteligentes centrales. La compañía reportó 672 problemas matemáticos resueltos por un costo de modelo de USD $111,85, pero reconoce que trasladar ese avance a software de producción exige especificaciones y comprobaciones adicionales.
***

  • NEAR planea llevar la verificación formal asistida por IA a su protocolo, contratos centrales y herramientas para desarrolladores.
  • Su agente resolvió 672 problemas de PutnamBench con un costo reportado de USD $111,85, sin incluir el desarrollo completo del sistema.
  • La compañía advierte que las pruebas matemáticas no certifican por sí solas la seguridad de una aplicación completa ni de su implementación desplegada.

NEAR busca blindar su protocolo con IA tras resolver 672 problemas por USD $111,85

Sumario: NEAR quiere trasladar la generación automatizada de pruebas matemáticas desde los benchmarks hasta el software que sostiene su red, aunque el resultado de laboratorio no equivale a una certificación de seguridad para contratos en producción.

Del benchmark matemático al código de la red

NEAR Protocol busca aplicar verificación formal asistida por inteligencia artificial a su protocolo, sus contratos inteligentes centrales y algunas herramientas para desarrolladores del ecosistema. La iniciativa parte de un avance de NEAR AI: un agente resolvió 672 problemas Lean de PutnamBench con un costo de modelo de USD $111,85, según la cifra presentada por el equipo.

La compañía explicó que su objetivo es reducir el trabajo especializado y los costos de cómputo necesarios para demostrar que un programa cumple reglas definidas. El anuncio del 16 de octubre presenta la aplicación al software de producción como un siguiente paso, no como una capacidad ya desplegada para certificar toda la red.

La diferencia es importante porque PutnamBench evalúa la capacidad de demostrar resultados matemáticos, mientras que un protocolo contiene código, dependencias y supuestos que deben conectarse con esas demostraciones. NEAR sostiene que resolver problemas de referencia sirve para ejercitar una habilidad necesaria, pero separa ese logro de la verificación de las propiedades del software implementado.

El plan apunta a cubrir componentes centrales y herramientas del ecosistema, pero la publicación no afirma que los contratos actuales ya hayan pasado por ese proceso. Para llegar a una garantía de producción, los desarrolladores primero necesitan representar con precisión el comportamiento del programa, expresar las propiedades que quieren preservar y comprobar que las pruebas corresponden a la versión que realmente utilizan los usuarios.

Qué mide el costo de USD $111,85

NEAR informó que su agente resolvió 672 problemas Lean vinculados con PutnamBench, una referencia basada en la competencia universitaria de matemáticas Putnam. El equipo indicó un costo promedio aproximado de USD $0,17 por problema con los precios de los modelos utilizados para la presentación, aunque esa cifra no representa el costo total de diseñar y construir el sistema.

El repositorio público del proyecto desglosa el conjunto como 670 problemas originales y versiones corregidas de otros dos que tenían formalizaciones defectuosas. También señala que, al repetir el mismo uso con precios fuera de horario de DeepSeek publicados posteriormente, el costo estimado sería de USD $331, un cálculo distinto al del anuncio inicial.

La contabilidad incluye intentos fallidos, de acuerdo con la metodología descrita por el equipo, pero excluye un experimento paralelo separado que utilizó Kimi. El repositorio también informa que la ejecución más larga superó los tres días y que el proceso contempló controles frente a pruebas incompletas y cambios en la afirmación matemática que se intentaba demostrar.

Junto con PutnamBench, NEAR dijo que su equipo alcanzó el primer lugar en el total de resoluciones del marcador Lean Eval v1. La compañía aclaró que esa clasificación mide el total de problemas resueltos y no debe confundirse con las primeras resoluciones o con la cantidad de soluciones únicas, distinciones que cambian la interpretación del desempeño.

Las garantías dependen de lo que se especifique

La verificación formal consiste en expresar una regla de software en términos matemáticos y demostrar que el programa la cumple bajo las condiciones definidas. NEAR ilustra la diferencia con una transferencia de tokens: una prueba convencional puede revisar una transacción concreta, mientras que una propiedad formal puede establecer que las transferencias cubiertas por el modelo conservan el saldo combinado de las cuentas.

Sin embargo, esa propiedad no demostraría por sí sola que solo las cuentas autorizadas pueden iniciar transferencias. Esa condición requeriría una especificación y una prueba adicionales, de modo que la garantía depende tanto de las reglas elegidas por los desarrolladores como de las suposiciones incorporadas al modelo matemático.

El flujo de trabajo descrito por NEAR utiliza Lean, un lenguaje de programación y asistente de pruebas de código abierto. Un agente de IA puede proponer una demostración, ejecutarla, revisar los comentarios del sistema y modificar el intento; el núcleo de Lean verifica si la prueba respeta las reglas lógicas establecidas.

Un intento fallido tampoco identifica automáticamente un error de software, según la explicación de NEAR: el requisito puede estar mal planteado, la implementación puede incumplirlo o el agente quizá no encuentre una demostración válida. Por eso la verificación formal debe acompañar las pruebas convencionales, la revisión de código y las prácticas de seguridad operativa, en lugar de sustituirlas.

Una etapa de investigación, no una certificación completa

El propio anuncio distingue entre demostrar una propiedad concreta y concluir que una aplicación entera es segura. Una prueba puede cubrir una regla contable importante, pero dejar fuera permisos, interacciones con otros componentes o diferencias entre el modelo y el código que opera en la red.

NEAR señaló que la producción exige modelos precisos del comportamiento del software y una conexión clara entre las pruebas y la implementación de la que dependen los usuarios. Esa condición vuelve decisiva la traducción de requisitos: una demostración solo puede respaldar aquello que los desarrolladores expresaron y que el verificador comprobó.

La verificación formal ya tiene antecedentes dentro del ecosistema. Una evaluación de Certora del protocolo de préstamos Templar, publicada el 30 de marzo, describe una revisión manual de contratos escritos en Rust y la especificación y verificación formal de su contrato de mercado; el informe completo identifica las propiedades probadas y los problemas encontrados.

El cofundador de NEAR, Illia Polosukhin, ha vinculado esta investigación con los riesgos del código generado por IA y con herramientas que pueden ayudar a atacantes a encontrar debilidades. En una declaración reproducida por NEAR, sostuvo que el futuro de la IA y del código generado por IA resulta prometedor, pero que hacen falta garantías matemáticas verificables sobre su comportamiento.

NEAR no está sola en la exploración

Otros equipos de blockchain también han descrito usos de IA para apoyar la verificación formal. En mayo, Aptos Labs presentó soporte para este enfoque en contratos Move con invocación dinámica y señaló un flujo de trabajo que emplea especificaciones generadas por IA junto con Move Prover.

Vitalik Buterin también ha hablado de combinar herramientas de IA con pruebas verificadas por máquinas. Sus comentarios de mayo abarcaron posibles aplicaciones en distintas áreas de la hoja de ruta de Ethereum, entre ellas el consenso, la criptografía resistente a la computación cuántica y los sistemas de conocimiento cero.

Buterin advirtió que demostrar una capa no prueba que el sistema completo se comporte como se espera, una cautela que coincide con la distinción que NEAR hace entre un benchmark matemático y un protocolo en funcionamiento. La discusión también contempló la verificación desde especificaciones de alto nivel hasta implementaciones de bajo nivel.

En paralelo, la investigación de seguridad de NEAR ha abordado firmas resistentes a la computación cuántica. En mayo, Near One propuso soporte para firmas FIPS-204, basadas en el estándar ML-DSA aprobado por el Instituto Nacional de Estándares y Tecnología de Estados Unidos, y planteó como objetivo una red de pruebas para finales del segundo trimestre de 2026; también advirtió que billeteras, hardware, puntos finales y API requerirían cambios coordinados.

Por ahora, el dato de USD $111,85 demuestra el costo de modelo reportado para un ejercicio de generación de pruebas, no el precio de auditar un contrato inteligente ni una garantía de seguridad integral. El siguiente desafío de NEAR será convertir esa capacidad en especificaciones rigurosas, pruebas vinculadas al código desplegado y controles que sigan complementando las revisiones humanas.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados