Estándares y Preparación para el Futuro
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.
Estándares de Codificación y Programas es el nivel de ingeniería del día a día; Convenciones de Documentación, Gobernanza de Dependencias y Crates, Directrices de Contribución, Programa de Auditoría y Recompensas por Errores y Picos, PoC y Adopción de Nuevas Herramientas se centran cada uno en una superficie de control. Esta página se sitúa debajo: cómo esas piezas forman durabilidad a nivel de organización en una pila de rápida evolución (esta guía: Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, @solana/kit 7.0.0).
Resumen
- 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.
Fundamentos
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 autoridadEstá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.
Mecánicas e Interacciones
Los estándares de codificación establecen la ruta predeterminada
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.
Los documentos hacen que la autoridad y las operaciones sean reproducibles
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 y los locks son política de producció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 puertas de contribución protegen el radio de explosión
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.
Las auditorías y recompensas cierran el bucle externo
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.
Los picos y PoC adoptan el cambio sin caos
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.
Cómo interactúan las piezas en un ciclo de lanzamiento
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 ADRLos 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.
Consideraciones Avanzadas y Aplicaciones
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.
Conceptos Erróneos Comunes
- "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.
Preguntas Frecuentes
¿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.
Relacionados
- Estándares de Codificación y Programas - convenciones para Anchor, programas nativos y clientes
- Convenciones de Documentación - normas para IDL, ADRs, runbooks y páginas de guía
- Directrices de Contribución - puertas de PR, CODEOWNERS y divulgación de seguridad
- Gobernanza de Dependencias y Crates - lockfiles, reglas de deny, compilaciones verificables
- Programa de Auditoría y Recompensas por Errores - preparación, remediación y operaciones continuas de recompensas
- Picos, PoC y Adopción de Nuevas Herramientas - evaluación con plazo definido y adopción en producción
Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0.