Prueba nuestro nuevo plugin de análisis dimensional de Claude

Estamos lanzando un nuevo complemento para Claude que permite desarrollar y auditar código, implementando análisis dimensional, una técnica que exploramos en nuestra última publicación de blog. La mayoría de las habilidades basadas en LLM piden al modelo que encuentre errores. Nuestro nuevo complemento para el análisis dimensional para Claude Code adopta un enfoque diferente: utiliza el LLM para anotar su código fuente con tipos dimensionales, y luego señala las discrepancias de forma mecánica. En las pruebas contra los hallazgos de auditoría reales, logró un 93% de recuperación frente a 50% para los prompts de referencia. Puede descargar y utilizar nuestro nuevo complemento para el análisis dimensional ejecutando estos comandos: claude plugin marketplace add trailofbits/skills claude plugin install dimensional-analysis@trailofbits claude /dimensional-analysis Cómo difiere nuestro complemento de la mayoría de las habilidades Esta publicación de lanzamiento es bastante diferente de la ola de habilidades de análisis de seguridad que se han lanzado en las últimas semanas. Las habilidades que hemos visto tienden a adoptar un enfoque relativamente simple, donde el LLM se inicializa con un conjunto de clases de vulnerabilidad, instrucciones de exploración y ejemplos de hallazgos, y luego se le indica que intente identificar errores dentro del alcance de la habilidad. Lamentablemente, estos enfoques tienden a producir resultados de baja calidad, con una precisión, recuperación y determinismo que a menudo son mucho peores que simplemente pedirle a un LLM que “encuentre los errores en este proyecto”. Lo que hace que el análisis dimensional sea diferente es que, en lugar de confiar en el juicio del LLM para buscar, identificar y clasificar las vulnerabilidades, utiliza el LLM como una máquina de construcción de vocabulario/categorización que anota directamente el código fuente. Si las anotaciones son correctas y existe una discrepancia dimensional, esa discrepancia aparece como una falta de coincidencia entre las anotaciones, en lugar de tener que depender del juicio de un LLM para determinar qué tan viable es el hallazgo. En efecto, esto cambia el cálculo de cómo se está utilizando la capacidad de razonamiento del LLM, y produce mejores resultados que los prompts de referencia que dependen demasiado de las capacidades de razonamiento del LLM. Evaluación Comparamos el análisis dimensional con un conjunto de problemas de discrepancias dimensionales encontrados durante varias auditorías no publicadas y lo comparamos con un prompt de referencia utilizando 10 muestras por código base. Para esta evaluación, el complemento de análisis dimensional tuvo una tasa de recuperación del 93% con una desviación estándar de 12%, frente al prompt de referencia, que tuvo una tasa de recuperación del 50% con una desviación estándar de 20%. Esto significa que el análisis dimensional funcionó mejor y de manera más consistente que el prompt de referencia. Cómo funciona Si aún no lo ha hecho, lea nuestra primera publicación de blog sobre la técnica de análisis dimensional. El complemento funciona en cuatro fases principales: descubrimiento de dimensiones, anotación de dimensiones, propagación de dimensiones y validación de dimensiones. En la primera fase, un subagente realiza el descubrimiento de dimensiones, con el objetivo de identificar un vocabulario de unidades base fundamentales de las que está compuesto cada término numérico del sistema. Durante este proceso, también identifica un conjunto de unidades derivadas comunes para referencia rápida por agentes posteriores. Figura 1: Un ejemplo de un vocabulario dimensional para un protocolo utilizando hooks de Uniswap v4 El vocabulario dimensional se guarda en DIMENSIONAL_UNITS.md, donde puede ser leído por otros agentes o utilizado durante el desarrollo si elige que las anotaciones sean parte permanente del ciclo de vida de desarrollo de su software. En la segunda fase, se lanzan un grupo de subagentes para anotar directamente el código fuente utilizando el vocabulario dimensional. Cada subagente se proporciona con el archivo DIMENSIONAL_UNITS.md, un conjunto de archivos para anotar y instrucciones para anotar variables de estado, argumentos de función, declaraciones de variables y cualquier porción de cálculos complejos. Estas anotaciones iniciales se denominan anotaciones “anclaje”. } else if (currentPrice < peakPrice) { // D18{1} = (D18{price} - D18{price}) * D18{1} / (D18{price} - D18{price}) imbalance = ((peakPrice - currentPrice) * imbalanceSlopeData.imbalanceSlopeBelowPeak) / (peakPrice - eclpParams.alpha.toUint256()); } else { // D18{1} = (D18{price} - D18{price}) * D18{1} / (D18{price} - D18{price}) imbalance = ((currentPrice - peakPrice) * imbalanceSlopeData.imbalanceSlopeAbovePeak) / (eclpParams.beta.toUint256() - peakPrice); } Figura 2: Un ejemplo de cálculos anotados de Balancer v3 En la tercera fase, las dimensiones se “propagan” a través de cada archivo a los llamantes y a los que llaman. Esta fase añade anotaciones adicionales a los archivos de baja prioridad que no recibieron anotaciones en la primera pasada, y realiza los primeros comprobados para asegurarse de que las dimensiones coinciden dentro del mismo contexto de código y a través de archivos. Es importante tener en cuenta que una discrepancia dimensional en esta etapa no necesariamente significa que existe una vulnerabilidad; a veces no es posible inferir la dimensión exacta de un argumento de función llamado sin leer la implementación de la función, y el sistema generalizará o hará una mala suposición. Esta tercera fase intenta “reparar” estas anotaciones generalizadas y, si la reparación no es posible, las marca para la gestión en el paso final. En la cuarta y última fase, el complemento intenta descubrir discrepancias y realizar la gestión. Se comprueban las discrepancias dimensionales durante la asignación, durante los cálculos, a través de los límites de función, a través de los caminos de retorno y a través de las llamadas externas. Las discrepancias dimensionales se comparan con una clasificación de gravedad en función de la naturaleza de la discrepancia, y se devuelve un informe final al usuario. ¿Qué sigue? Si es un desarrollador que trabaja en un proyecto intensivo en aritmética, como un contrato inteligente o un nodo de blockchain, le recomendamos encarecidamente que ejecute este complemento, y que comite DIMENSIONAL_UNITS.md junto con todas las anotaciones creadas por el complemento. Además de encontrar errores, estas anotaciones pueden mejorar significativamente el tiempo que se tarda en comprender un código base complejo y pueden ayudar a mejorar tanto la comprensión humana como la del LLM del significado semántico de las expresiones aritméticas de su proyecto. Aunque las nuevas herramientas son emocionantes, en este momento no creemos que esta herramienta pueda encontrar todas las fuentes de errores dimensionales. Los LLM son probabilísticos, lo que significa que siempre habrá algún nivel de error. Estamos interesados en mejorar este complemento siempre que sea posible, por lo que si lo ejecuta y no encuentra ninguna discrepancia dimensional, le rogamos que abra un problema en nuestro repositorio de GitHub.