Visión general de frameworks ligeros
Pinocchio y Steel ofrecen abstracciones más delgadas sobre solana-program que Anchor 0.32.1, intercambiando macros y azúcar de IDL por una menor sobrecarga de CU y binarios más pequeños. Los equipos los eligen cuando la economía de la ruta crítica importa.
Receta
Comparar: Anchor (velocidad) vs Pinocchio (dependencias mínimas) vs Steel (nativo ergonómico). Perfila antes de cambiar.
Cuándo recurrir a esto:
- El presupuesto de CU bloquea el lanzamiento del producto.
- El tamaño del binario está cerca de los límites de despliegue.
- Construcción de infraestructura reutilizada por muchos llamadores.
Ejemplo de trabajo
Ejes de decisión:
1. Experiencia del equipo en Anchor vs. profundidad de Rust en sistemas
2. CU p99 de la instrucción crítica (simular)
3. Necesidad de IDL incorporado vs. pipeline de Codama
4. Capacidad de revisión de seguridad para validación manualLo que esto demuestra:
- La elección del framework es económica, no moral.
- Muchos equipos usan Anchor para la capa de aplicación + núcleo nativo/Pinocchio.
- Interoperabilidad a través de CPI entre estilos.
Inmersión profunda
Comparación de pilas
| Framework | Deps | IDL | CU Típico |
|---|---|---|---|
| Anchor 0.32.1 | Más alto | Incorporado | Línea base |
| Pinocchio | Mínimo | Externo | Más bajo |
| Steel | Ligero | Externo | Medio-bajo |
| Nativo | Mínimo | Manual | Techo más bajo |
Migración
Perfil de Anchor -> reescribir hot ix en el módulo Pinocchio (avanzado).
Trampas
- Reescribir sin métricas - Complejidad sin ganancia. Solución: Simular primero.
- Perder IDL accidentalmente - Rotura del cliente. Solución: Codama/kinobi.
- Subestimar las comprobaciones manuales - Regresión de seguridad vs Anchor. Solución: Validación mediante lista de verificación.
- Fijar todas las versiones - Desviación de Agave 4.1.1. Solución: Bloquear la cadena de herramientas.
- Ignorar la historia del cliente - Los constructores de TS todavía necesitan esquemas. Solución: Publicar IDL JSON.
Alternativas
| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
| Permanecer en Anchor | Aplicaciones predeterminadas | Dolor de CU probado |
| Nativo completo | Máximo control | Velocidad más lenta |
| CPI híbrido | Dividir preocupaciones | Dos desplegables |
Preguntas frecuentes
¿Pinocchio listo para producción?
Usado en programas críticos de rendimiento - evaluar por equipo.
¿Steel vs Pinocchio?
Steel añade ergonomía; Pinocchio el más mínimo.
¿Anchor muerto?
No, por defecto para la mayoría de los equipos.
¿Ruta de aprendizaje?
Anchor y luego los internos de Pinocchio.
¿LiteSVM todo?
Sí, para pruebas.
¿Generación de IDL?
Codama a partir de anotaciones.
¿Ruta de actualización?
Volver a desplegar un nuevo ID de programa o autoridad de actualización.
¿Compilación verificable?
El mismo solana-verify.
¿Números de CU?
Perfilado - sin % universal.
¿Seguridad?
La carga de validación manual es mayor.
¿Agave 4.1.1?
SDK de Pin en toda la pila.
¿Comunidad?
Ecosistema ligero en crecimiento.
Relacionado
- Conceptos básicos de Pinocchio - Inicio
- Cuándo usar cada framework - Lista de verificación
- Ganancias en CU y tamaño de binario - Métricas
Versiones de la pila: Esta página se escribió 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.