Toma de Decisiones Técnicas
Los líderes técnicos de Solana se enfrentan a bifurcaciones de alto riesgo: Anchor vs Pinocchio, claves custodiales vs no custodiales, programas actualizables vs inmutables. Las buenas decisiones enmarcan las opciones, puntúan las compensaciones explícitamente y se comprometen con un propietario documentado y una fecha de revisión.
Cómo Usar Esta Lista
- Usa cada plantilla de decisión cuando dos ingenieros senior no estén de acuerdo durante más de una reunión.
- Clasifica las opciones para tu contexto: "Mejor" asume DeFi de producción, no un hackathon.
- Registra el resultado en un ADR dentro de las 48 horas.
- Establece la fecha de revisión del ADR cuando se publiquen las versiones menores de Agave o Anchor.
Decisión 1: Anchor vs Nativo (Pinocchio) para un Nuevo Programa
Escenario: Programa Greenfield; el equipo conoce Anchor 0.32.1; el presupuesto de CU puede importar a escala.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Anchor | IDL, pruebas, restricciones; lanzar en un sprint |
| 2º | Pinocchio / nativo | Ruta crítica sensible a la CU después de que el perfilado demuestre la necesidad |
| 3º | Steel | Ligero cuando la sobrecarga de Anchor es demasiado alta pero se desean algunas ergonomías |
Elección incorrecta: Nativo desde el primer día para "evitar la hinchazón" sin datos de CU: duplica la superficie de revisión de seguridad.
Por qué la mejor es la mejor: Las macros de restricciones de Anchor codifican las comprobaciones de Sealevel; las firmas de auditoría reconocen patrones; la velocidad del equipo importa antes de la PMF.
Decisión 2: Programa Actualizable vs Inmutable
Escenario: Lanzamiento de una bóveda de préstamos con depósitos de usuarios.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Actualizable + multisig + pausa | Corregir errores; simular retroceso |
| 2º | Inmutable | Solo después de auditorías y sin cambios de lógica planificados |
| 3º | Clave activa actualizable | Nunca para fondos de usuarios en producción |
Elección incorrecta: Inmutable en el lanzamiento "para parecer descentralizado": no se puede parchear un exploit sin migración.
Por qué la mejor es la mejor: Los exploits de Solana se mueven rápido; la actualización multisig con compilaciones verificables equilibra la confianza y la seguridad.
Decisión 3: SDK de Cliente - @solana/kit vs Legacy web3.js
Escenario: Nueva dApp Next.js en 2026.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | @solana/kit 7.0.0 | RPC tipado, codecs, tree-shakeable |
| 2º | Cliente TS de Anchor | CPI de Anchor pesada desde el mismo repositorio |
| 3º | web3.js v1 | Solo mantenimiento legado |
Elección incorrecta: Proyecto nuevo con patrones no mantenidos: el costo de migración golpea en el pico de lanzamiento.
Por qué la mejor es la mejor: Kit se alinea con el RPC de Agave 4.1.1 y la dirección a largo plazo de la fundación Solana.
Decisión 4: RPC - Proveedor Único vs Múltiple
Escenario: Aplicación de billetera de producción; 10k DAU.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Escritura principal + conmutación por error de lectura secundaria | SWQoS en la ruta de envío |
| 2º | Proveedor premium único | Aceptable por debajo de 2k DAU con SLA |
| 3º | RPC público | Solo desarrollo |
Elección incorrecta: RPC público de mainnet para el día de acuñación: los límites de tasa se convierten en tu interrupción.
Por qué la mejor es la mejor: La disponibilidad de aterrizaje y lectura dominan los tickets de soporte; la conmutación por error es más barata que el MTTR del incidente.
Decisión 5: Indexador - Construir vs Comprar
Escenario: Necesidad de historial más allá de getSignaturesForAddress del RPC.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Indexador administrado (Helius, etc.) | Lanzar producto; SLAs |
| 2º | Autoalojamiento gRPC de Yellowstone | Escalar o análisis personalizado |
| 3º | Encuestar RPC en cron | Solo prototipo |
Elección incorrecta: Bucles GPA en la ruta de la API a escala: 429 tu propia producción.
Por qué la mejor es la mejor: El tiempo de ingeniería se gasta mejor en la seguridad del programa que en el indexador de operaciones, a menos que sea una competencia central.
Decisión 6: Pruebas - LiteSVM vs Validador de Pruebas
Escenario: CI para PRs de programas Anchor.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | LiteSVM 0.6.x en CI | Rápido, determinista |
| 2º | Surfpool 0.12.0 | Escenarios de clonación de cuentas de Mainnet |
| 3º | solana-test-validator | Depuración manual local |
Elección incorrecta: Devnet como puerta de control de CI: inestable y con límites de tasa.
Por qué la mejor es la mejor: Las pruebas de subsegundo permiten la regresión de seguridad en cada PR.
Preguntas Frecuentes
¿Cuántas opciones por decisión?
Tres como máximo en el documento de decisión; más causa fatiga.
¿Quién toma la decisión final?
Líder técnico o arquitecto; aportación del PM sobre compensaciones visibles para el usuario.
¿Cuándo revisar una decisión?
Fecha de revisión del ADR o actualización material de Agave/Anchor.
¿Desacuerdo y compromiso?
Registrar la disidencia en el ADR; el partidario es responsable de las métricas de resultado.
¿Picos antes de decidir?
Limitar el tiempo a 2-3 días para CU o incógnitas de aterrizaje.
¿Gobernanza comunitaria?
Votos de tokens para parámetros del protocolo; ADR de ingeniería para implementación.
¿Signos de fatiga en la toma de decisiones?
El mismo debate cada sprint: ADR faltante o propietario poco claro.
¿Aportación de ingenieros junior?
Requerido en la revisión de diseño; el propietario de la decisión sigue siendo un senior nombrado.
¿Cuándo escalar?
Irreversible + alto riesgo de fondos + desacuerdo después de dos reuniones.
¿Ubicación de la plantilla?
docs/adr/ en el repositorio; enlace desde el README de arquitectura.
Relacionado
- Registros de Decisiones de Arquitectura (ADR) - documentar resultados
- Ejecución de Revisiones de Diseño - facilitar el debate
- Manejo de Desacuerdos Técnicos - desescalada
Versiones de la pila: Esta página fue escrita para 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.