Plano de Estudios de Caso
Los estudios de caso y las compilaciones de referencia en Solana son artefactos de aprendizaje estructurados: una forma de problema conocida, un grafo concreto de cuentas e instrucciones, puertas de enlace operativas y resultados medibles. Úsalos para transferir patrones a tu programa, cliente y runbook de lanzamiento, no como productos para bifurcar ciegamente.
Esta sección contiene tres tipos de artefactos: compilaciones de referencia (programa DeFi + dApp, lanzamiento de token SPL, mint de cNFT), estudios de antes/después (CU/renta y aterrizaje) y conocimiento de fallas (retrospectivas de seguridad más un catálogo de lecciones). Esta página mapea cómo usar esos artefactos como un único sistema de aprendizaje, no un resumen de cada uno.
Resumen
- Trata cada estudio de caso como un bucle transferible: marco del problema → grafo de cuentas e instrucciones → cliente y ruta de inclusión → puertas de enlace de operaciones y autoridad → medición → captura de lecciones - luego, vuelve a aplicar ese bucle a tu producto con los pines de tu stack.
- Por Qué Importa: Las fallas de producción en Solana rara vez provienen de "no saber Rust". Provienen de una composición incompleta: comprobaciones de firmantes faltantes, CU no medida, autoridad de mint dejada activa, RPC público el día del mint, o lecciones que nunca vuelven a entrar en la revisión de diseño. Los estudios de caso codifican esas costuras en un formato que puedes auditar.
- Conceptos Clave: compilación de referencia, antes/después, retrospectiva, catálogo de lecciones, marco del problema, grafo de cuentas, puertas de enlace de operaciones, resultado medible, control de prevención, pines de stack.
- Cuándo Usar: Arquitectura Greenfield, incorporación de ingenieros full-stack, preparación de auditorías, listas de verificación de lanzamiento, revisiones de diseño post-incidente y elección de profundidad (referencia vs optimización vs seguridad).
- Limitaciones / Compensaciones: Las referencias son simplificadas; los lugares de mainnet y las profundidades de los árboles cambian; las métricas de un equipo no son tus líneas base; las retrospectivas enseñan clases de errores, no recetas de exploits paso a paso; el sobreajuste a un repositorio de muestra congela el diseño del producto.
- Temas Relacionados: Programa DeFi + dApp, lanzamiento de token SPL, mint de cNFT a escala, optimización de CU y renta, aterrizaje confiable, retrospectivas de seguridad, catálogo de lecciones.
Fundamentos
Un estudio de caso de Solana solo es valioso cuando hace explícitas las restricciones. La cadena no se preocupa de que tu producto sea un mercado o un juego. Le importan las cuentas que pasas, los programas en los que haces CPI, quién firma, cuánto cómputo consumes, si se paga la renta, y si el líder incluye tu transacción bajo contención.
Las páginas hermanas en esta sección responden a diferentes preguntas:
| Tipo de artefacto | Pregunta principal | Ejemplo en esta sección |
|---|---|---|
| Compilación de referencia | ¿Cómo se ve un camino completo? | Programa DeFi + dApp, lanzamiento de token SPL, mint de cNFT |
| Antes/después | ¿Qué cambió y en qué medida? | Optimización de CU/renta, aterrizaje de transacciones |
| Retrospectiva | ¿Cómo funcionó esta clase de falla? | Retrospectivas de incidentes de seguridad |
| Catálogo | ¿Qué se repite y qué control lo detiene? | Catálogo de lecciones aprendidas |
Marco del problema (intención + riesgo)
|
v
+---------------------------+
| Forma de referencia | cuentas, ix, cliente, pruebas
+-------------+-------------+
|
v
+---------------------------+
| Medición | CU, renta, tasa de aterrizaje, costo
+-------------+-------------+
|
v
+---------------------------+
| Endurecimiento | clase de seguridad + puertas de enlace de operaciones
+-------------+-------------+
|
v
Entrada al catálogo de lecciones + control de CILas compilaciones de referencia enseñan composición (diseño, PDAs, cliente kit, simular y luego enviar, autoridad). Los estudios de antes/después enseñan evidencia (línea base, cambio, remensura). Las retrospectivas enseñan modelos de amenaza. El catálogo es memoria a largo plazo para que las trampas no vuelvan como historias de Slack únicas.
La regla: extraer principios, redescubrir para tus restricciones, probar con pruebas y métricas. Copiar carpetas de monorepos sin redescubrir las comprobaciones de cuentas, tarifas y autoridad es culturismo de carga.
Mecánicas e Interacciones
Cómo leer una compilación de referencia
Trabaja una página de referencia en cuatro pasadas, no en un escaneo rápido.
- Marco del problema. ¿Qué intención del usuario está en la cadena (depósito, mint, lanzamiento, inventario a escala)? ¿Qué está deliberadamente fuera de alcance (legal, valores, riesgo completo del lugar)?
- Grafo de cuentas e instrucciones. ¿Qué cuentas propiedad del programa, mints, ATAs, PDAs y programas externos aparecen? ¿Qué debe ser escribible vs. solo lectura?
- Ruta del cliente. ¿Cómo
@solana/kit(o CLI) construye, simula, firma y confirma? ¿Dónde aparecen las cantidades bigint, el entorno del clúster y la versión del IDL? - Puertas de enlace de operaciones. Autoridad de actualización multisig, política de autoridad de mint/congelación, plan de RPC, verificación del explorador, hash del artefacto de lanzamiento.
Solo después de esas cuatro pasadas deberías abrir la inmersión profunda hermana para ver el detalle línea por línea. La referencia es el mapa; otras secciones poseen la teoría.
Superficies de referencia en esta sección
Usa cada referencia para una habilidad de composición diferente:
- Referencia: Un Programa DeFi + dApp - monorepo, Anchor, LiteSVM, Next.js + kit, autoridad de pausa y despliegue; mantener alineados el estado en cadena y la simulación/envío.
- Referencia: Un Lanzamiento de Token SPL - mint, metadatos, matemáticas de distribución, revocación de autoridad; puertas de enlace de operaciones irreversibles que el marketing no puede anular.
- Referencia: Un Mint de NFT Comprimido a Escala - capacidad del árbol, Bubblegum, DAS, lotes y tarifas; compensaciones de costo e inventario que las cuentas NFT ordinarias ocultan.
No fusiones estos en una única "aplicación de plantilla". Comparten reglas de tiempo de ejecución, no grafos de productos.
Cómo leer un antes/después
Las páginas de antes/después entrenan la disciplina de medición.
- Captura una línea base bajo un stack y carga de trabajo nombrados (bench de LiteSVM, tiempo p95 hasta la confirmación, tasa de aterrizaje).
- Cambia un subsistema a la vez cuando sea posible (reescritura de instrucción en caliente, oráculo de tarifas, ALT, RPC privado).
- Remensura con el mismo arnés.
- Mantén una guardia de regresión (bench en CI, alerta del panel de aterrizaje).
- Antes/Después: Optimizando un Programa para CU y Renta - perfilar primero; cero-copia y frameworks más ligeros solo donde los caminos calientes los justifiquen.
- Antes/Después: Haciendo que las Transacciones Aterricen Confiablemente - el aterrizaje como métrica de producto; tarifas de prioridad, ALTs, estrategia de confirmación, Jito opcional.
Los números ilustran el método, no tus garantías. Vuelve a ejecutar las líneas base en tus pines (por defecto del sitio: Agave 4.1.1, Anchor 0.32.1, Rust 1.91.1, @solana/kit 7.0.0) antes de reclamar una victoria.
Cómo leer retrospectivas de seguridad
Las retrospectivas mapean clases de exploits a mecánicas de Sealevel: comprobaciones de firmante o propietario faltantes, sustitución de cuentas, orden de CPI, frescura del oráculo, concentración de privilegios. Léelas como indicaciones de modelo de amenaza:
Clase de incidente público
|
v
¿Qué comprobación faltaba o estaba mal ordenada?
|
v
¿Cuáles de nuestras instrucciones comparten esa forma?
|
v
Prueba LiteSVM (o bankrun) que falla sin la corrección
|
v
ID del catálogo + casilla de verificación de revisión de diseñoUsa Retrospectivas de Incidentes de Seguridad para anatomía y patrones de respuesta (pausa, instantánea, parche, verificación, comunicación). No las trates como tutoriales de ataque; la prevención y las pruebas de regresión son el producto.
Cómo usar el catálogo de lecciones
El Catálogo de Lecciones Aprendidas es el índice, no una narrativa. Cada entrada debe llevar severidad, área (programa / cliente / operaciones), una falla de una línea, un puntero de prevención (documento + CI), y una fuente (incidente, auditoría, fecha).
Hábitos operativos que hacen real el catálogo:
- Abre la revisión de diseño con "¿hay algún golpe del catálogo en esta superficie de instrucción?"
- Después de cada auditoría o cuasi-accidente, agrega o actualiza una ID antes de cerrar el ticket.
- Separa las lecciones de programa, cliente y operaciones para que el propietario correcto posea el control.
- Vincula la prevención a una página y a una comprobación automatizada cuando sea posible (prueba de restricción de firmante, puerta de enlace de hash IDL, piso de tarifas en rutas de mint).
Un pase de aprendizaje a través de toda la sección
Un bucle práctico de equipo para una nueva característica:
- Elige la referencia más cercana (forma DeFi, operaciones de token o mint a escala).
- Completa la hoja de trabajo de cuatro pasadas (marco, cuentas, cliente, operaciones).
- Extrae las expectativas de CU, renta y aterrizaje de las páginas de antes/después en los criterios de aceptación.
- Modela amenazas con clases de retrospectiva; agrega pruebas fallidas para tus caminos.
- Agrega o marca entradas del catálogo; envía solo cuando existan controles de prevención.
Ese bucle es el plano. Los artículos hermanos son combustible para los pasos 1-4; el catálogo es la memoria del paso 5.
Consideraciones Avanzadas y Aplicaciones
Elegir la profundidad por riesgo
| Situación | Empezar con | Profundizar luego |
|---|---|---|
| Nueva característica full-stack | Referencia de programa DeFi + dApp | Antes/después de CU/renta y aterrizaje antes de la carga en mainnet |
| Lanzamiento de token o puntos | Referencia de lanzamiento de token SPL | Lecciones de autoridad y operaciones en el catálogo |
| Gran caída o inventario de juego | Referencia de mint de cNFT | Antes/después de aterrizaje + operaciones DAS |
ComputationalBudgetExceeded | Antes/después de CU/renta | Revisión de seguridad de caminos calientes después de la reescritura |
| Carga de soporte "Pendiente para siempre" | Antes/después de aterrizaje | Entradas del catálogo de RPC y tarifas |
| Auditoría o incidente | Retrospectivas + catálogo | Re-verificación de referencia de autoridad y CPI |
Lista de verificación de transferencia (usar en cada estudio)
Copia esto en las revisiones de diseño; complétala a partir del estudio de caso, no de memoria.
- Pines de stack: Agave/CLI, Anchor, Rust, kit, hash IDL.
- Grafo de cuentas: propietarios, firmantes, PDAs, mints, IDs de programas externos.
- Modos de falla: falla de simulación, falla de aterrizaje, multi-tx parcial, pausa.
- Economía: renta, tarifas de prioridad/propinas, modelo de costo de cuenta o árbol.
- Autoridad: mint, congelación, actualización, pausa, actualización de metadatos.
- Prueba: IDs de pruebas LiteSVM o de integración; hash del explorador o de lanzamiento para operaciones.
- IDs de lecciones: referencias nuevas o existentes en el catálogo.
Antipatrones al usar estudios de caso
- Bifurcar un monorepo de referencia y enviarlo sin redescubrir las restricciones.
- Tratar los porcentajes de antes/después como SLAs sin volver a hacer pruebas de referencia.
- Estudiar exploits sin agregar una prueba fallida que bloquee la corrección.
- Entradas en el catálogo sin propietarios o ganchos de CI (rotación de wiki).
- Optimizar CU antes de que la instrucción sea correcta y autorizada.
- Planificar un mint de 100k en RPC público sin política de tarifa de prioridad cero porque la receta del camino feliz funcionó en devnet.
Cómo se relacionan los estudios de caso con el resto del sitio
Las secciones de teoría (cuentas, PDAs, seguridad, solución de problemas de producción, integraciones DeFi) poseen los mecanismos. Esta sección posee composiciones trabajadas y bucles de retroalimentación. Cuando una referencia menciona pausa, ALTs o revocación de mint, sigue la inmersión profunda enlazada para la regla; mantén el estudio de caso como la narrativa de extremo a extremo y la historia de medición.
Conceptos Erróneos Comunes
- "Una compilación de referencia es un producto que debería enviar." Es una forma de enseñanza. Tus restricciones de mercado, custodia y cumplimiento aún requieren un diseño completo.
- "Si leo cada estudio de caso una vez, estoy listo para producción." La preparación son grafos redescubiertos, pruebas, métricas y controles de catálogo en tus instrucciones.
- "Los números de antes/después se transfieren entre programas." Las cargas de trabajo, los tamaños de cuenta y la congestión difieren. El método se transfiere; los porcentajes brutos no.
- "Las retrospectivas de seguridad son solo para auditores." Cada ingeniero que escribe una instrucción que mueve valor es responsable de la clase de falla correspondiente.
- "El catálogo de lecciones es documentación opcional." Sin él, la misma reintentación de
Signerfaltante o blockhash obsoleto regresa bajo un nuevo título de ticket. - "El aterrizaje y la CU son temas de infraestructura, no material de estudio de caso." En Solana son calidad de producto visible para el usuario y costo; las páginas de antes/después existen por esa razón.
- "Los lanzamientos de tokens cNFT y SPL son el mismo problema operativo." Los temas compartidos (autoridad, tarifas, RPC) se basan en modelos de cuenta e indexación diferentes; usa la referencia correspondiente.
- "El código del cliente no necesita entradas de lecciones." Montos flotantes, clúster incorrecto, deriva de IDL y tarifa de prioridad cero son fallas recurrentes del cliente con las mismas etiquetas de severidad que los errores del programa.
Preguntas Frecuentes
¿Cuál es la diferencia entre una compilación de referencia y un tutorial?
Un tutorial enseña una sola habilidad de forma aislada. Una compilación de referencia muestra un camino compuesto (programa, pruebas, cliente, puertas de enlace de operaciones) para que puedas ver dónde se encuentran las habilidades y qué puertas de enlace son irreversibles.
¿Qué página debo abrir primero en esta sección?
Comienza aquí para el patrón de aprendizaje, luego la referencia más cercana a tu producto (dApp DeFi, lanzamiento de token o cNFT). Agrega material de antes/después y de seguridad antes de la carga en mainnet o la auditoría.
¿Cómo adapto una referencia a Pinocchio o Rust nativo si la muestra es Anchor?
Mantén el grafo de cuentas, la política de autoridad y los casos de prueba; cambia solo la capa de implementación. El antes/después de CU/renta es el complemento para la extracción de caminos calientes, no una razón para omitir las pruebas de corrección.
¿Qué métricas debe rastrear cada equipo después de estudiar el aterrizaje?
Tasa de aterrizaje a tu compromiso objetivo, tiempo p95 hasta la confirmación por ruta crítica, gasto de tarifas y propinas, y relación simulación-exitosa vs. inclusión-fallida bajo carga máxima.
¿Qué métricas importan después de un estudio de CU/renta?
CU por instrucción caliente, tamaño de transacción, renta de cuenta para PDAs centrales y benches de regresión en CI para que una característica posterior no borre la victoria.
¿Con qué frecuencia debemos revisar el catálogo de lecciones?
Al menos al inicio de la revisión de diseño para nuevas superficies de instrucción, después de cada ciclo de incidente o auditoría, y en una limpieza trimestral para mantener la precisión de la severidad y los propietarios.
¿Los estudios de caso reemplazan las auditorías formales?
No. Mejoran el modelado de amenazas interno y la cobertura de regresión. Un alto TVL o custodia todavía necesita una revisión independiente; las entradas del catálogo rastrean la remediación de esa revisión.
¿Por qué fijar las versiones de stack en el trabajo de estudio de caso?
Las cadenas de herramientas de Solana y los kits de cliente se mueven. Una receta que funcionó en una versión anterior de Anchor o kit puede inducir a error. Revalida en tus pines (este sitio apunta a Agave 4.1.1, CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, @solana/kit 7.0.0).
¿Cómo deben usar los nuevos ingenieros esta sección en su primera semana?
Una compilación de referencia de extremo a extremo en devnet o localnet, una lectura del método antes/después con un bench pequeño, y un recorrido por cinco entradas del catálogo relacionadas con fallas de firmante, CPI y aterrizaje.
¿Qué pertenece a un post-mortem que alimenta el catálogo?
Cronología, clase de causa raíz, radio de explosión, corrección, verificación (ID de prueba o prueba en cadena), y una ID de catálogo con una prevención propiedad de un equipo.
¿Puedo omitir la referencia DeFi si solo envío NFTs?
Puedes comenzar con cNFT o lanzamiento de token, pero aún así leer material de aterrizaje y seguridad. Los productos de inventario fallan en la inclusión, la autoridad y las comprobaciones de cuentas con la misma frecuencia que los productos DeFi.
¿Cómo aparecen ALTs y Jito en el patrón de aprendizaje?
Son herramientas de inclusión, no características de producto. Estúdialos en el antes/después de aterrizaje cuando la tasa de aterrizaje o el flujo atómico de múltiples ix sea parte de los criterios de aceptación.
¿Qué es un "control de prevención" en el lenguaje del catálogo?
Una guardia concreta: restricción de Anchor, prueba unitaria, puerta de enlace de hash CI, piso de tarifas, política multisig o paso de runbook que habría bloqueado la trampa.
¿Cómo sé que la transferencia de un estudio de caso está completa?
Puedes nombrar tu grafo de cuentas, política de autoridad, ruta de simulación/envío del cliente, presupuestos de CU y aterrizaje, pruebas de seguridad para clases relevantes y IDs de catálogo para riesgos residuales, sin referirte al nombre del producto de muestra.
Relacionados
- Referencia: Un Programa DeFi + dApp - composición de programa Anchor, pruebas y cliente kit
- Referencia: Un Lanzamiento de Token SPL - mint, metadatos, distribución, revocación de autoridad
- Referencia: Un Mint de NFT Comprimido a Escala - árboles, Bubblegum, DAS, costo a escala
- Antes/Después: Optimizando un Programa para CU y Renta - reducción medida de caminos calientes y renta
- Antes/Después: Haciendo que las Transacciones Aterricen Confiablemente - tarifas, ALTs, confirmación, Jito opcional
- Catálogo de Lecciones Aprendidas - trampas recurrentes con punteros de prevención
Versiones de Stack: 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.