¡Saludos estimados lectores!
Hoy vamos a mirar algunos consejos profesionales en la auditoría de contratos inteligentes en la blockchain de NEAR. En esta serie, nos vamos a enfocar en esos aspectos que pueden ser realmente útiles para auditar proyectos basados en NEAR. ¡Todo lo que vas a encontrar a continuación, se basa en nuestra experiencia personal!
En primer lugar, nos gustaría expresar nuestro más sincero agradecimiento a los creadores de NEAR y los proyectos de su ecosistema, a todos los que lo apoyan, los autores de los materiales informativos y por supuesto, a nuestros brillantes auditores que nos han ayudado a revelar información tan necesaria y así levantar la cortina del secreto. Y hoy, queridos lectores, estará disponible para ustedes.
Podemos decir con confianza que estos consejos se pueden leer de forma pública en varios lugares, ¡y nuestro blog es uno de esos lugares! A continuación, te traemos nuestras observaciones: hechos innegables para auditores, trucos y los top hacks compartidos por nuestros mejores auditores. ¡Vamos a comenzar!
Por cierto, en estos momentos tenemos algunos espacios vacantes, así que si tu proyecto necesita una auditoría, escríbenos, visita nuestra página de informes públicos aquí.
I — ¿Qué es NEAR?
NEAR es una plataforma de desarrollo, construida sobre una blockchain de capa uno fragmentada y de Prueba de Participación. Gracias a la tecnología de fragmentación, NEAR ofrece soluciones a problemas como la velocidad de procesamiento, congestión de la red y altas comisiones por gas, permitiendo una escalabilidad significativa de la plataforma sin sacrificar la seguridad del protocolo.
Es importante tener en mente que NEAR es una blockchain fragmentada escalable, lo que quiere decir que los contratos inteligentes que se ejecutan, se compilan en WebAssembly (WASM) y pueden ser escritos en lenguajes como:
- Rust
- AssemblyScript (un tipo de lenguaje TypeScript para WebAssembly)
- Solidity (vía Aurora EVM)c
- Javascript (vía JS-VM)
El uso de WASM da como resultado un alto límite de gas y eficiencia, una generación rápida de bloques y tarifas de transacción bajas. Los contratos inteligentes en NEAR pueden considerarse como microservicios que contienen datos y códigos ejecutables. Las interacciones entre los contratos cruzados se realizan de forma asíncrona.
Con todo lo dicho, desde nuestra perspectiva, el Ecosistema NEAR está, en su mayoría ¡basado en Rust!
https://github.com/rust-in-blockchain/awesome-blockchain-rust
La plataforma reúne a miles de miembros de la comunidad para brindar la mejor experiencia, así como, un amplio ecosistema multifuncional:
La plataforma se basa en varias características claves:
En términos de seguridad de producción de bloques, emplea un mecanismo conocido como Doomslug. El Doomslug, a pesar de su nombre ominoso, es muy sencillo y asume que diferentes validadores toman turnos para producir bloques en función de la cantidad de tokens NEAR stakeados.
No iremos a los detalles en este artículo porque asumimos que tú, querido lector, ya tienes suficiente entendimiento sobre el ecosistema de NEAR, así que te recomendamos que visites su base de conocimientos y estudies la documentación del proyecto para una mejor comprensión:
II — Procedimiento de Revisión del Proyecto NEAR por el Equipo de Pessimistic.io:
Debido a que los principales obstáculos que un auditor puede tener mientras audita proyectos en NEAR, son lógicos; la primera sugerencia para cualquier firma será un desarrollo competente, que dé como resultado una documentación sólida y pruebas confiables. Esto parece muy simple para ser verdad, ¡pero asegúrate de que funcione y se pruebe así misma en el tiempo!
Así pues, nuestro brillante equipo de auditoría desea presentarte nuestro conjunto de reglas, acumuladas durante muchos meses y años de trabajo, en el cual trataremos de evitar la redundancia y trataremos de transmitir todo de forma concisa y profesional. Con lo anterior dicho, realizamos nuestras auditorías de acuerdo a los siguientes procedimientos:
Análisis Automatizado:
- Recopilamos contratos;
- Corremos las pruebas proporcionadas y revisamos la cobertura del código;
- Ejecutamos herramientas de análisis y verificamos manualmente (rechazamos o confirmamos) todos los problemas informados (ver a continuación).
Auditoría Manual
- Revisamos manualmente códigos y evaluamos su calidad;
- Verificamos el código en búsqueda de vulnerabilidades conocidas;
- Revisamos si la lógica del código cumple con la documentación entregada;
- Sugerimos posibles optimizaciones de gas y almacenamiento;
Problemas:
Estamos activamente en la búsqueda de:
- Problemas de control de acceso (identificación/autorización incorrecta de administradores o usuarios);
- Problemas de activos perdidos/robados (activos atascados en el contrato o enviados a ninguna parte o a una cuenta incorrecta);
- DoS debido a problemas lógicos (interbloqueo, error de máquina de estado, etc.);
- DoS debido a problemas técnicos (error de falta de gas, otras limitaciones);
- Problemas de interacción del contrato (reentrada, llamadas inseguras, suposiciones de la persona que llama);
- Problemas aritméticos (desbordamiento, subdesbordamiento, problemas de redondeo);
- Uso incorrecto de Near SDK;
- Otros problemas.
Gas:
Verificamos si las operaciones intensivas de gas se ejecutan de forma eficiente:
- Colecciones: las colecciones de std::collections se leen todas juntas, lo que infla el consumo de gas. Debes usar near_sdk::collections o near_sdk::store;
- Las colecciones están vinculadas a un almacenamiento y puedes accidentalmente olvidarte de sincronizarlas;
- Mapas: LookupMap / UnorderedMap / TreeMap: debes elegir de acuerdo con la funcionalidad requerida (el primero es el más barato, el último el más poderoso);
- LazyOption: para los “big data” raramente utilizados (solo se pueden usar en el constructor);
- Borsh/JSON para la serialización de mensajes (parámetros/valores de retorno) — afecta el consumo de gas;
- Mira de cerca el ataque “million cheap data additions” para evitar problemas similares.
Herramientas:
Vamos a darle una mirada a las herramientas de análisis automáticos que puedes usar en tu trabajo y sus características:
- Valgrind: se puede usar si el código incluye bloques inseguros con una asignación de memoria peligrosa. Sin embargo, tal práctica levanta una bandera roja para la auditoría. En general, ejecutar valgrind no tiene mucho sentido.
- Cargo Geiger es una herramienta que muestra estadísticas sobre el uso inseguro del código Rust, en una caja Rust y todas sus dependencias. Su capacidad para concentrarse en posibles problemas es una característica beneficiosa. La existencia de un código peligroso ya es un problema en dichos proyectos, y dichas entradas deben verificarse dos veces.
- Cargo Audit: verifica los archivos en busca de cajas que contienen vulnerabilidades de seguridad. Es decir, muestra bibliotecas desactualizadas que todavía se usan. Sin embargo, debes utilizarlo para fines de auditoría.
- Clippy, el analizador estático, es un filtro de código increíble para detectar errores comunes y mejorar su código Rust.
- Cargo Tarpaulin, para cobertura de prueba, una herramienta muy útil que revela la cantidad de líneas de código que no están cubiertas por las pruebas.
III —Auditoría de Informes Públicos
Nuestras auditorías de informes públicos de los proyectos del ecosistema NEAR, están estructurados de acuerdo con el esquema de flujo de auditoría presentado anteriormente, por lo que te recomendamos que compares estos informes, en particular sus resultados, con los siguientes:
¡Esperamos que este artículo haya sido informativo y útil! ¡Gracias por leer! ¿Qué instrumentos deberíamos revisar? ¿Qué te interesaría leer en nuestro blog?
Si todavía tiene consultas, ¡no dudes en preguntar! ¡Estaremos encantados de responder todas las interrogantes que tengas! ¡Las mejores preguntas y respuestas pueden incluirse en la próxima publicación del blog!
Por cierto, ahora hay algunos espacios vacantes, así que si tu proyecto necesita una auditoría, no dudes en escribirnos, visita nuestra página de informes públicos aquí.
