Estándares y preparación para el futuro para los equipos de Solana son las políticas, las puertas de revisión y los bucles de seguridad continuos que mantienen seguros los programas, clientes y operaciones a medida que cambian las personas, el TVL y las herramientas del ecosistema. Una vez que trate las convenciones de codificación, la documentación, la gobernanza de crates, las reglas de contribución, las auditorías, las recompensas y la adopción controlada de herramientas como un único sistema operativo (no una pila de páginas wiki), los lanzamientos en mainnet dejarán de depender del conocimiento tribal y los heroísmos.
Los productos de Solana de larga duración necesitan una capa de gobernanza de ingeniería (cómo se escribe, revisa, documenta, aprueba dependencias, audita y actualiza el código) que sea tan explícita como la validación de cuentas en la cadena.
Por Qué Importa: Sealevel y Anchor detectan muchos errores en tiempo de ejecución; no previenen crates de la cadena de suministro, deriva silenciosa de IDL, claves de actualización únicas, rutas de administración no revisadas o reescrituras imprudentes de herramientas bajo presión de lanzamiento.
Conceptos Clave:estándares de codificación, ADR y runbooks, política de crates y lockfile, puertas de contribución y CODEOWNERS, auditoría externa + recompensa por errores, picos/PoC, compilaciones verificables, higiene de la autoridad de actualización, seguimiento del cambio del ecosistema.
Cuándo Usar: Al formar un equipo de protocolo, preparar el primer TVL en mainnet, abrir el código fuente de un monorepo, incorporar contratistas o madurar de "funciona en mi portátil" a operaciones de múltiples lanzamientos.
Limitaciones / Compensaciones: El proceso tiene un costo; el exceso de políticas detiene el envío. Adapte el rigor al riesgo de los fondos y al tamaño del equipo. Los estándares se pudren sin aplicación de CI y propietarios.
Temas Relacionados: estándares de codificación, convenciones de documentación, gobernanza de dependencias, directrices de contribución, auditorías y recompensas.
La ingeniería de Solana falla en dos lugares a la vez: tiempo de ejecución (cuentas incorrectas, matemáticas sin verificar, malos objetivos de CPI) y organización (sin propietario para las actualizaciones, sin lista de prohibición de crates, documentación solo en Slack, auditoría como fecha de calendario en lugar de estado de preparación). Las habilidades de tiempo de ejecución residen en las guías de programas y clientes. Esta sección se ocupa del segundo modo de fallo.
Piense en seis bucles de control acoplados:
Estándares de codificación ----> menos clases de errores en la revisión Documentación (IDL, ADR, runbooks) ----> decisiones y operaciones reproducibles Gobernanza de crates / lock ----> binario más pequeño + superficie de cadena de suministro Puertas de contribución ----> quién puede tocar programas y cuándo Auditoría + recompensa ----> prueba externa y divulgación continua Picos / PoC ----> adopción segura de Surfpool, kit, Pinocchio, ... | v Organización preparada para el futuro: fijar pila, programar actualizaciones, documentar autoridad
Estándares de codificación responden: ¿cómo se ve el código correcto de Anchor 0.32.1 y kit-client aquí? Nomenclatura, aritmética verificada, constantes para IDs de programa, sin matemáticas de tokens flotantes, clippy y rustfmt en CI.
Convenciones de documentación responden: ¿dónde reside la verdad después de que se fusiona el PR? IDL versionado junto a los lanzamientos, ADR inmutables, runbooks con propietario y reversión, no arqueología de chat.
Gobernanza de dependencias y crates responde: ¿qué crates pueden entrar en programs/, cómo se revisan las actualizaciones, cómo Cargo.lock y cargo deny y las compilaciones verificables demuestran el grafo que se envía.
Directrices de contribución responden: listas de verificación de PR, CODEOWNERS, ruta de divulgación de seguridad y qué significa "hecho" para los cambios de programas, documentos o clientes.
Auditorías y recompensas por errores responden: cómo los especialistas externos y los white-hats extienden la revisión interna antes y después del lanzamiento.
Picos y PoC responden: cómo el equipo evalúa nuevas herramientas del ecosistema sin migraciones parciales permanentes.
La preparación para el futuro no es predecir cada SIMD. Son fijaciones, propietarios, calendarios y disparadores de re-auditoría para que los cambios en Agave, Anchor, Rust y los SDK de clientes sean trabajo planificado en lugar de trabajo de incidentes.
Los estándares codifican los errores que te niegas a redescubrir. Centraliza los IDs de CPI y programa en constants, documenta las semillas de PDA en las estructuras de cuenta, requiere aritmética checked_*, prohíbe unwrap en rutas de programa y aplica cargo fmt / clippy en CI. Los clientes se estandarizan en @solana/kit 7.0.0 para nuevo trabajo y tratan las cantidades como enteros (bigint), nunca como flotantes.
Sin una barra escrita, cada PR reinventa el estilo y cada auditoría encuentra las mismas "semillas mágicas" y "cadenas de IDs de programa duplicadas". Detalle: Estándares de Codificación y Programas.
Las operaciones de Solana son de alto riesgo: hashes de implementación, runbooks de pausa, pasos de actualización de multisig, tablas de semillas de PDA para integradores. Las convenciones de documentación colocan ADRs, runbooks y artefactos de IDL en git junto al código que describen. La semver de IDL se vincula a las etiquetas de lanzamiento del programa. Los runbooks enumeran el propietario, el respaldo, los requisitos previos, los pasos, la reversión y la verificación (comprobaciones de hash de solana-verify / programa).
Las firmas de auditoría y los nuevos empleados fallan cuando la arquitectura vive solo en la cabeza de un ingeniero. Detalle: Convenciones de Documentación.
Los crates en cadena deben permanecer mínimos: prefiera anchor-lang, solana-program y una lista de permitidos corta. Confirme Cargo.lock para los espacios de trabajo del programa. Ejecute cargo deny para avisos, licencias y prohibiciones. Revise las actualizaciones de SPL/Anchor en PR dedicados con diffs de hash ejecutables cuando cambien las dependencias del programa. Las compilaciones verificables (anchor build --verifiable, solana-verify) demuestran que el resultado del grafo de dependencias coincide con lo que afirma implementar.
La cadena de suministro y el tamaño binario no son "agradables de tener en infraestructura"; son CU, superficie de auditoría y confianza. Detalle: Gobernanza de Dependencias y Crates.
Las directrices de contribución definen la protección de ramas, los recuentos de revisión en programs/, los commits convencionales, el correo de seguridad privado y CODEOWNERS. Los cambios en la interfaz del programa requieren pruebas y actualizaciones de IDL. Los cambios arquitectónicos requieren ADRs. Los cambios que afectan las operaciones requieren actualizaciones de runbooks. Los problemas de seguridad nunca comienzan como problemas públicos de GitHub con detalles de explotación.
Los monorepos internos necesitan la misma disciplina que el código abierto; los contratistas y los contribuyentes a tiempo parcial amplifican el riesgo sin puertas de control. Detalle: Directrices de Contribución.
Los estándares internos reducen el ruido; no reemplazan a los especialistas. Un paquete de preparación para auditoría incluye el alcance (IDs de programa, SHA de commit, lista fuera de alcance), índice de arquitectura y ADR, modelo de amenazas, ruta LiteSVM / cargo test-sbf en verde y IDL coincidente. Las puertas de remediación detienen mainnet TVL para Crítico/Alto. Las re-auditorías solo de diff cubren actualizaciones materiales. Una recompensa por errores (niveles claros, puerto seguro, SLA de triaje) permanece activa después del lanzamiento para que la divulgación continua tenga un canal.
Las auditorías no son un certificado que nunca expira. Trátelas como instantáneas más pruebas de regresión vinculadas a los IDs de hallazgo. Detalle: Programa de Auditoría y Recompensas por Errores.
La superficie de herramientas de Solana evoluciona rápidamente: versiones de kit, LiteSVM, Surfpool, Codama, Pinocchio, APIs de proveedores de RPC. Los picos responden a una pregunta con plazo definido con un resultado escrito. Los PoC demuestran la viabilidad con métricas. La adopción requiere un ADR, propietario, ruta de CI y la eliminación o promoción de la rama con pruebas.
Las reescrituras impulsadas por el bombo a mitad del lanzamiento crean pilas duales permanentes (web3.js y kit, dos ejecutores de pruebas, dos scripts de implementación). El proceso previene tanto la beta eterna como las instalaciones imprudentes en producción. Detalle: Picos, PoC y Adopción de Nuevas Herramientas.
Rama de características | v Estándares de codificación + pruebas + clippy/fmt (CI) | v ¿Actualización de dep? -> cargo deny + diff de hash + revisión ¿Cambio de interfaz? -> IDL + clientes regenerados ¿Cambio de arquitectura? -> ADR ¿Cambio de operaciones? -> runbook | v Fusión a través de CODEOWNERS | v Compilación verificable + implementación bajo multisig/autoridad de gobernanza | v ¿Cambio material? -> re-auditoría / actualización del alcance de la recompensa ¿Nueva herramienta? -> solo si el pico/PoC ya se cerró con ADR
Los estándares sin CI son sugerencias. Las auditorías sin pruebas de regresión son souvenirs. Las recompensas sin pruebas de triaje son marketing. Los picos sin ADR son ramas abandonadas que se convierten en producción en la sombra.
Los equipos no necesitan todos los controles desde el primer día. Adapte el riesgo de los fondos, el tamaño del equipo y la exposición pública a una ruta de madurez, y luego agregue bucles a medida que aparezcan el TVL y los integradores externos.
Ruta de madurez
Lo que ejecutas
Fortalezas
Debilidades
Mejor ajuste
Núcleo de inicio
Estándares de codificación + CI de fmt/clippy, lockfile confirmado, CONTRIBUTING básico, ADRs de propietario único
Rápido; cubre la mayoría de los errores tempranos
Revisión externa delgada; concentración de autoridad
Productos pre-TVL, herramientas internas
Listo para Mainnet
Arriba + deny.toml, pin de IDL, runbooks, autoridad de actualización multisig, auditoría previa al lanzamiento, plan de recompensas
Listo para auditoría y operaciones
Costo del proceso; necesita propietario de seguridad
Fondos de primer usuario, IDs de programa públicos
Organización de protocolo
Arriba + CODEOWNERS, política de re-auditoría, calendario trimestral del ecosistema, plantilla de picos, alcance/autoridades públicas
Confianza del integrador; supervivencia al cambio de personal
Burocracia si se aplica en exceso a crates de bajo riesgo
Alto TVL, multi-programa, código abierto
Ecosistema abierto
CONTRIBUTING público, alcance divulgado, plataforma de recompensas, hashes publicados, estándares de documentación comunitaria
Contribuyentes externos; transparencia
Carga de soporte; riesgo de ingeniería social
Bienes públicos y grandes DAO
Núcleo de inicio es correcto cuando el producto aún está encontrando su ajuste al mercado y tiene poco capital de usuario. No omita los lockfiles y el formato CI ni siquiera aquí; son baratos.
Listo para Mainnet es el mínimo para programas que custodian o enrutan valor significativo. La autoridad de actualización multisig o controlada por gobernanza, las compilaciones verificables y una cola de auditoría Crítica/Alta cerrada son más importantes que la estética perfecta de wiki.
Organización de protocolo agrega gobernanza continua: quién revisa las prohibiciones de crates, cuándo se actualiza el calendario del ecosistema, cómo los picos entran en la hoja de ruta y cómo el alcance de las recompensas rastrea las nuevas instrucciones.
Ecosistema abierto optimiza para contribuyentes externos y confianza pública. Publique IDs de programa, hashes y política de divulgación; mantenga canales privados para seguridad.
Para las revisiones de diseño, responda primero: quién tiene la autoridad de actualización, qué aplica la CI, dónde viven los IDL y ADRs, cuándo fue el último SHA de auditoría, si el triaje de recompensas tiene personal y cómo una nueva herramienta obtiene un ADR.
"Escribiremos los estándares después del lanzamiento." El lanzamiento es cuando la deuda del proceso se acumula bajo presión de incidentes; los estándares base deben preceder al TVL.
"Una auditoría reemplaza los estándares de codificación y la CI." Los auditores muestrean una instantánea; la CI aplica cada fusión. Ambos son necesarios.
"Cargo.lock es solo para aplicaciones." Los espacios de trabajo de programas necesitan grafos reproducibles para compilaciones, auditorías y análisis de incidentes.
"La documentación es para gerentes de producto." Los runbooks y ADRs son herramientas de ingeniería; no tenerlos es un error de disponibilidad y seguridad.
"Cualquier crate en crates.io está bien si compila." Las dependencias en cadena expanden la CU, el tamaño binario y la superficie de auditoría; la prohibición y la revisión son políticas.
"La recompensa por errores puede esperar hasta que seamos famosos." La recompensa al lanzar canaliza la divulgación; el silencio no significa ausencia de investigadores.
"Adoptamos la herramienta porque un hilo de Twitter la elogió." Sin un resultado de pico y un ADR, usted posee una dependencia no poseída para siempre.
"Los programas inmutables no necesitan gobernanza." La inmutabilidad es una decisión con consecuencias de documentación y operaciones; los clientes, el IDL y las dependencias aún necesitan estándares.
"Un ingeniero con la clave de actualización está bien si es de confianza." Los puntos únicos de fallo son un riesgo organizacional, no solo un riesgo criptográfico.
¿Cuál es la idea más importante en estándares y preparación para el futuro?
Trate la gobernanza de ingeniería (cómo funcionan el código, los documentos, las dependencias, las revisiones, las auditorías y la adopción de herramientas) como infraestructura de primera clase, con la misma seriedad que la validación de cuentas en la cadena.
¿Cuándo debería un equipo pequeño invertir en esto?
Tan pronto como aparezcan fondos de usuarios, IDs de programas públicos o contribuyentes externos. Antes de eso, mantenga un núcleo delgado: CI fmt/clippy, lockfile, contacto de seguridad privado y plan de autoridad de actualización escrito.
¿Cómo se relacionan los estándares de codificación con los programas Anchor y nativos?
Las reglas de seguridad (aritmética verificada, validación explícita, sin rutas de pánico) se comparten. El código nativo agrega más comprobaciones manuales de cuentas; Anchor codifica muchas a través de restricciones. Los estándares documentan ambos caminos que permite su monorepo.
¿Por qué fijar Agave, CLI, Anchor, Rust y kit juntos?
Las versiones de toolchain desajustadas crean compilaciones de "funciona en mi máquina", compilaciones verificables fallidas y desajustes entre cliente y tiempo de ejecución. Esta guía fija Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0 como un conjunto de autoría coherente.
¿Qué pertenece a un ADR vs un runbook?
Los ADRs capturan decisiones duraderas y alternativas consideradas. Los runbooks capturan pasos de operaciones ejecutables con reversión y propietarios. Las características a menudo necesitan ambos.
¿Es cargo deny suficiente para la seguridad de la cadena de suministro?
Es una política necesaria como código para avisos, licencias y prohibiciones, pero no es suficiente por sí sola. Empareje con dependencias mínimas en cadena, actualizaciones revisadas y compilaciones verificables.
¿Con qué frecuencia deberíamos re-auditar?
Después de cambios materiales en la lógica o el diseño de cuentas, no en cada error tipográfico. Presupueste re-auditorías solo de diff en la hoja de ruta; mantenga las regresiones de LiteSVM para hallazgos anteriores.
¿Qué hace que una recompensa por errores sea útil desde el primer día?
IDs de programa en alcance publicados, niveles de gravedad, lenguaje de puerto seguro, rotación de triaje y SLAs de respuesta. Las páginas vacías sin triaje con personal desperdician investigadores y reputación.
¿En qué se diferencian los picos de las migraciones de producción?
Los picos responden a una pregunta en un plazo definido y terminan en un informe o ADR. La migración de producción requiere propietarios, CI, documentos y un corte explícito; nunca promueva código de pico por accidente.
¿Debería la autoridad de actualización ser una hot wallet?
No para TVL significativo. Use multisig o gobernanza en cadena, documente las direcciones y practique simulacros de firma. La inmutabilidad es una decisión documentada alternativa, no un silencio predeterminado.
¿Cómo interactúan las directrices de contribución con la divulgación de seguridad?
Las características normales usan el proceso de PR. Los exploits sospechosos usan primero la divulgación privada. Nunca requiera problemas públicos para hallazgos de seguridad.
¿Dónde encaja el seguimiento del cambio del ecosistema?
Mantenga un calendario continuo para Agave, Anchor, kit y el impacto relevante de SIMD. Los estándares le dicen cómo actualizar; el calendario le dice cuándo planificar el trabajo.
¿Cómo ayudan los estándares con la migración de @solana/kit?
Un ADR y un pico deciden la adopción de kit; los estándares de codificación prohíben pilas duales para código nuevo; la gobernanza de dependencias fija kit 7.0.0; las reglas de contribución requieren pruebas de cliente; los documentos actualizan el IDL y los runbooks de la aplicación juntos.