Buenas Prácticas para Programas Nativos
El código nativo se encarga de cada verificación de seguridad. Estas prácticas mantienen los programas pequeños, legibles y resistentes a exploits comunes de Solana.
Cómo Usar Esta Lista
- Revisa cada instrucción nueva contra la sección A antes de fusionar.
- Mantén una tabla de metadatos de cuentas en la documentación del repositorio.
- Ejecuta
cargo build-sbfy las pruebas de LiteSVM en CI.
A - Validación Explícita
- Documenta el orden de las cuentas en una tabla por instrucción. Los clientes y auditores comparten una única fuente de verdad.
- Valida los firmantes antes de las mutaciones de datos escribibles. Detiene cambios de estado no autorizados.
- Verifica las PDAs con los "bumps" canónicos almacenados en la cadena. Bloquea ataques de fuerza bruta de semillas.
- Rechaza claves públicas duplicadas en rutas de tokens. Previene la manipulación de saldos.
- Carga las sysvars a través de "getters" tipados, no mediante cuentas pasadas. Evita la inyección de sysvars falsas.
B - Estructura y Claridad
- Una función "handler" por variante de instrucción. Simplifica auditorías y pruebas.
- Centraliza el análisis y despacho en el módulo "processor". Punto de entrada único para los bytes de la instrucción.
- Mantén las funciones auxiliares puras siempre que sea posible. Facilita las pruebas unitarias en el host.
- Publica un enum de códigos de error que coincida con los valores en cadena. Los clientes decodifican los fallos de manera consistente.
- Versiona el esquema de instrucciones con un byte explícito. Soporta actualizaciones sin ambigüedad.
C - Despliegue y Operaciones
- Fija el SDK de
solana-programa la cadena de herramientas Agave 4.1.1. Construcciones reproducibles. - Produce artefactos de compilación verificables. Los usuarios confían en el bytecode desplegado.
- Captura instantáneas de CU por instrucción en las pruebas. Detección de regresiones.
- Minimiza las dependencias en el "crate" del programa. Superficie de ataque y binaria más pequeña.
- Cero datos al cerrar; dirige el alquiler deliberadamente. Previene ataques de reactivación.
Preguntas Frecuentes
¿El equipo de Anchor se pasa a nativo?
A menudo solo las rutas críticas ("hot paths"), no toda la aplicación.
¿Cuántos revisores?
Al menos un revisor enfocado en seguridad de Solana.
¿Se requiere IDL?
Muy recomendado para clientes.
¿Objetivos de fuzzing?
El analizador de instrucciones y el validador de cuentas.
¿Usar macros?
Pequeñas macros internas están bien; evita el flujo de control oculto.
¿Diseño de módulos?
instruction, processor, state, error estándar.
¿Clippy en SBF?
Ejecutar en pruebas de configuración del host.
¿Documentar CPIs?
Lista los programas llamados y los cambios de privilegios.
¿Despliegue inmutable?
Escrutinio adicional antes de quemar la clave de actualización.
¿Nativo + Token-2022?
Valida explícitamente los diseños de extensiones.
¿Surfpool local?
Entorno de desarrollo predeterminado por manifiesto.
¿Código abierto?
Fomentado para la auditabilidad.
Relacionados
- Validación Manual de Cuentas - Detalles de la lista de verificación
- Buenas Prácticas de Rust para Solana - Hábitos de lenguaje
- Auditoría de Seguridad de Programas - Preparación de auditoría
Versiones de la pila: Esta página fue escrita para la cadena de herramientas Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.