Pinocchio En Profundidad
Los frameworks de programas de Solana residen en el mismo runtime: bytecode SBF, metadatos de cuenta explícitos, medición de unidades de cómputo (CU) e CPI. Lo que cambia es la cantidad de validación, codegen y pegamento de cliente que el framework genera para ti.
Anchor 0.32.1 optimiza la velocidad de desarrollo y un pipeline completo de IDL. Pinocchio y Steel optimizan para abstracciones más delgadas, binarios más pequeños y un control más estricto sobre el costo de las rutas críticas ('hot paths').
Esta página es el paraguas de la sección: por qué existen los frameworks ligeros, cómo se relacionan Pinocchio y Steel con Anchor y el solana-program nativo, cómo pensar en las CU y el tamaño binario, cómo funcionan realmente la interoperabilidad y la migración, y cuándo cada opción está justificada.
Resumen
- Los frameworks ligeros (Pinocchio, Steel) son toolkits más delgados de estilo nativo que reducen la sobrecarga de macros y dependencias para que puedas validar cuentas, despachar instrucciones y hacer CPI con menos código generado que Anchor, a costa de más trabajo manual de seguridad y esquemas de cliente.
- Por Qué Importa: Muchos productos nunca necesitan salirse de Anchor; algunos alcanzan límites de CU, presión de tamaño de despliegue o preferencias de auditoría que recompensan las comprobaciones explícitas. Elegir la pila incorrecta desperdicia meses; elegir la correcta (o un límite de CPI híbrido) es una decisión económica, no un concurso de pureza.
- Conceptos Clave: Pinocchio, Steel, Anchor, programa nativo, unidades de cómputo (CU), tamaño binario (
.so), IDL / Codama, punto de entrada, validación manual, interoperabilidad CPI, reescritura de ruta crítica ('hot path'). - Cuándo Usar: Orientar a un equipo sobre las opciones de framework; justificar una reescritura con métricas; diseñar un perímetro de Anchor + núcleo Pinocchio; decidir si el punto intermedio de Steel encaja; planificar la migración sin romper los diseños de cuenta o los clientes.
- Limitaciones / Compensaciones: Pierdes las macros de restricciones de Anchor y la historia de IDL predeterminada; la superficie de revisión de seguridad aumenta; la generación de código de cliente se convierte en un pipeline explícito; las ganancias desaparecen si la CPI de Token o las llamadas al sistema dominan el presupuesto de instrucciones.
- Temas Relacionados: Visión general de frameworks ligeros, conceptos básicos de Pinocchio, construcción de programas, Steel, ganancias de CU y tamaño binario, interoperabilidad y migración, y cuándo usar cada framework.
Fundamentos
Un programa de Solana sigue siendo una cuenta ejecutable que implementa aproximadamente process_instruction(program_id, accounts, data). Los frameworks difieren en el cableado del punto de entrada, las superficies de AccountInfo, y cuánta validación y pegamento de cliente generan.
Por qué existen los frameworks ligeros
El valor de Anchor es real: estructuras de cuentas, atributos de restricciones, errores y clientes impulsados por IDL en @solana/kit 7.0.0. Esa conveniencia tiene un costo en peso de dependencias, verificaciones expandidas por macros y patrones que pueden inflar las CU y el tamaño .so en rutas críticas.
Los frameworks ligeros responden a una pregunta del producto, no a un concurso de pureza: ¿podemos mantener la corrección mientras pagamos menos por instrucción y por despliegue?
Aparecen cuando las instrucciones críticas alcanzan el presupuesto de CU, el tamaño del binario o el costo de despliegue duele, los auditores prefieren verificaciones explícitas, o un núcleo compartido multiplica cada CU ahorrada a través del volumen. No existen porque Anchor sea incorrecto. Anchor 0.32.1 sigue siendo el predeterminado para la mayoría de los programas de aplicación.
Pinocchio vs Anchor (y vs nativo puro)
| Dimensión | Anchor 0.32.1 | Pinocchio | Nativo puro | Steel |
|---|---|---|---|---|
| Ergonomía | Máxima | Baja-media | Mínima | Media |
| Deps / pegamento | Mayor | Mínimo | Mínimo | Ligero |
| Validación | Restricciones declarativas | Manual | Manual | Ayudantes + convenciones |
| IDL / clientes | Ruta incorporada | Externo (Codama / manual) | Manual | Externo |
| CU / tamaño | Base más alta | A menudo más bajo cuando se mide | Techo más bajo | Bajo-medio |
| Mejor ajuste | MVP, admin, apps estándar | Núcleos críticos ('hot cores') | Máxima transparencia | Nativo multi-ix + estructura |
Pinocchio es un crate Rust mínimo para programas de estilo nativo: macro de punto de entrada, información de cuenta, pubkeys, errores y ayudantes de invocación, generalmente con un árbol pequeño y una postura compatible con #![no_std]. Aún así:
- Entras a través de
entrypoint!(process_instruction). - Analizas los datos de la instrucción (código de operación, Borsh o personalizado).
- Validas firmantes, escriturabilidad, propietarios, PDAs y layout tú mismo.
- Mutas cuentas y haces CPI con
invoke/invoke_signed.
No obtienes la red de seguridad de las macros #[derive(Accounts)] de Anchor. Ese es tanto el punto como el riesgo.
Steel se sitúa entre Pinocchio y Anchor: más estructura de instrucción/cuenta que Pinocchio puro, menos maquinaria de macros e IDL que Anchor. Úsalo cuando Pinocchio se sienta demasiado desnudo pero el perfil de costo de Anchor sea incorrecto.
CU y tamaño binario
Las CU miden el trabajo de las instrucciones. El tamaño binario es la huella del .so desplegado (y la economía de despliegue). Las pilas ligeras pueden reducir el pegamento del framework, desalentar el logging pesado en rutas críticas y fomentar parsers ajustados. No pueden borrar los mínimos de llamadas al sistema, las bases de CPI de SPL Token / Token-2022, ni tu algoritmo.
"Reescribimos en Pinocchio" no es una métrica. Las unitsConsumed simuladas en una transacción fija, más el tamaño del .so de lanzamiento, son una métrica.
Interoperabilidad, migración y elección
Los programas interoperan a través de CPI y bytes de cuenta compartidos, no frameworks compartidos. Anchor puede llamar a Pinocchio (y viceversa) cuando las metadatos, propietarios, discriminadores y semillas de PDA coinciden. La migración generalmente congela los layouts y semillas, mueve primero una ruta crítica, ejecuta en paralelo o crea límites de CPI durante el cambio, actualiza Codama/IDL con los clientes, y luego ajusta la autoridad de actualización después de métricas y revisión.
Por defecto, usa Anchor hasta que el perfilado, el tamaño o las restricciones de auditoría obliguen a lo contrario. Prefiere híbridos sobre reescrituras masivas. Pinocchio para núcleos mínimos; Steel para estructura sin Anchor completo; nativo puro cuando el equipo ya domina la disciplina completa de solana-program.
Mecánicas e Interacciones
La elección del framework se manifiesta en entrada/despacho, validación, estado y CPI, y clientes.
Cliente (Kit / Codama / ix hecho a mano)
|
v
Transacción nombra cuentas + id de programa
|
v
Runtime carga programa SBF (.so)
|
v
Punto de entrada -> parsear ix -> validar cuentas
|
+--> mutar datos propiedad del programa
+--> CPI a System / Token / otros
|
v
CU consumida; éxito o ProgramError
Punto de entrada y despacho. Pinocchio se parece a nativo: una entrada, luego coincidencia o desempaquetado de enum. Steel añade estructura de estilo registro para programas multi-instrucción. Anchor genera despacho desde el módulo del programa y los tipos de cuentas. Los tres siguen siendo un único ID de programa SBF para el runtime.
Validación. Anchor codifica las verificaciones de firmante, mut, propietario, semillas y token como atributos. Pinocchio las reimplementa en Rust, idealmente a través de ayudantes compartidos. Omitir verificaciones para "ahorrar CU" casi nunca vale la pena: el costo de la explotación supera con creces los ahorros de cómputo.
Estado y PDAs. Mantén una única fuente de verdad para discriminadores, orden de campos, semillas/bumps de PDA y códigos de error. A través de límites de CPI o migración, los bytes y las semillas deben coincidir, no solo los nombres de campo conceptuales.
CPI entre pilas. Formas típicas: Admin de Anchor -> núcleo de liquidación de Pinocchio; Pinocchio -> System/Token; aplicación Steel -> ecosistema de programas de Anchor. El orden de las cuentas y la escriturabilidad deben coincidir con el llamado. Las macros del framework no alinean automáticamente las listas de CPI entre crates.
Clientes e IDL. La fortaleza de Anchor es la IDL a clientes tipados. Pinocchio y Steel necesitan Codama (o codecs hechos a mano). @solana/kit 7.0.0 no se preocupa por qué framework construyó el .so; necesita formatos de cableado correctos. Presupuesta el trabajo del cliente cuando dejas Anchor.
Medición de ganancias.
- Línea base de CU p50/p99 en un gráfico de cuentas fijo (Surfpool / simular).
- Reescribe solo la instrucción crítica o extrae un núcleo de CPI.
- Resimula entradas idénticas; compara el tamaño del
.sode lanzamiento. - Bloquea los techos de CU en LiteSVM/CI.
Si la CPI de Token domina, arregla el algoritmo o el diseño de la cuenta antes de buscar frameworks.
Consideraciones Avanzadas y Aplicaciones
Arquitectura híbrida
Las reescrituras completas son raras. Una forma de producción común:
| Capa | Pila | Razón |
|---|---|---|
| Admin, config, ops | Anchor 0.32.1 | Velocidad, IDL, superficie de ix familiar |
| Emparejamiento / liquidación / 'hot mint' | Pinocchio o Steel | CU y tamaño bajo carga |
| Estado compartido | Diseños estables + discriminadores versionados | Actualizaciones seguras |
| Clientes | Kit + Codama (IDL de Anchor donde aún es Anchor) | Constructores tipados |
Invierte esfuerzo en sistemas donde la CU sea crítica para el producto; mantén Anchor donde la CU sea barata.
Seguridad y tamaño más allá del cambio de framework
Dejar Anchor aumenta la superficie de revisión: cada firmante, propietario, PDA, enlace de cuentas restantes y código de error es de propiedad manual. Invierte en ayudantes de validación, pruebas de invariantes y fuzzing de parsers. Trata la eliminación de restricciones como un proyecto de seguridad, no solo como un proyecto de rendimiento.
El tamaño también proviene de crates pesados en cadena, msg!/formato en rutas críticas, serialización duplicada y características no utilizadas. Perfila cargo build-sbf de lanzamiento y vuelve a medir después de las actualizaciones de Agave 4.1.1 / CLI.
Steel, patrones de migración y una rúbrica de decisión
Steel es una apuesta de proceso: las convenciones reducen los errores más rápido que el minimalismo puro sin el costo completo de Anchor. Úsalo cuando el número de instrucciones sea alto, varios programas necesiten patrones compartidos, y aún aceptes IDL externa más seguridad manual. Perfila Steel contra Anchor y Pinocchio en tu instrucción crítica.
| Patrón | Usar cuando | Vigilar |
|---|---|---|
| Extracción de CPI (nuevo id de programa) | Núcleo crítico aislable | Despliegue dual, autoridad |
| Reescribir en el lugar (in-place) | Mismo id, mismos layouts | Clave de actualización, compilaciones verificables |
| Ejecución paralela de clientes | Cambio gradual | Dos esquemas en vuelo |
| Mantener Anchor, optimizar interno | Dolor de CU leve | Logs, zero-copy, flags |
Nunca cambies layouts casualmente a mitad de la migración sin una ix de migración versionada y un plan para clientes.
Puntúa aproximadamente 0-2 cada uno: habilidad con Anchor, margen de CU, presión de binario, necesidad de IDL incorporada, plazo de auditoría, profundidad de Rust en sistemas.
- Baja presión de CU/tamaño + fuerte necesidad de IDL -> Anchor.
- Alta presión de CU/tamaño + Rust fuerte + dispuesto a usar Codama -> Pinocchio (o Steel si la estructura ayuda).
- Superficie mixta -> CPI híbrida.
- No seguro -> Anchor hasta que la simulación demuestre el dolor.
Adjunta números de simulación a un ADR corto para que el próximo debate de reescritura comience con datos.
Conceptos Erróneos Comunes
- "Pinocchio siempre usa menos CU que Anchor." A menudo cierto en rutas pesadas de framework, nunca garantizado. Las llamadas al sistema y la CPI de Token pueden dominar; mide transacciones fijas.
- "Dejar Anchor significa menos verificaciones de seguridad." Eres responsable de cada verificación que Anchor solía generar. Ligero no significa seguridad más ligera.
- "Debemos reescribir todo el programa." Una instrucción crítica o un núcleo de CPI a menudo capturan la mayor parte de la ganancia con menos riesgo.
- "Steel es inutilizable / Pinocchio siempre está listo para producción." Ambos son elecciones de pila. Fija las versiones de los crates a Agave 4.1.1 y tu barra de auditoría.
- "Los clientes inventarán el formato de cableado." Sin IDL o Codama, los clientes TypeScript se pudren. Publica esquemas con los despliegues.
- "El tamaño binario es cosmético." Los archivos
.somás grandes afectan el costo de despliegue y la fricción operativa. - "La elección del framework reemplaza el diseño del algoritmo." Gráficos de cuentas malos y CPIs extra pierden ante cualquier pila. Arregla el diseño cuando los perfiles lo indiquen.
Preguntas Frecuentes
¿Qué es Pinocchio en una frase?
Un framework Rust mínimo para programas de estilo nativo de Solana que prioriza una pequeña superficie de dependencias y ayudantes de bajo overhead para entrada, cuentas y CPI en comparación con Anchor.
¿Por qué existen los frameworks ligeros si Anchor es popular?
Algunos programas alcanzan techos de CU, límites de tamaño de despliegue o preferencias de auditoría por verificaciones explícitas; las pilas más delgadas intercambian conveniencia por control en esas rutas.
¿Está Anchor obsoleto?
No. Anchor 0.32.1 sigue siendo la pila de velocidad predeterminada; los frameworks ligeros son herramientas especializadas, no un reemplazo universal.
¿Cómo difiere Pinocchio de `solana-program` puro?
Mismo modelo general (punto de entrada, cuentas, validación manual) con una API de crate enfocada dirigida a un menor overhead y un árbol de dependencias más ajustado.
¿Dónde encaja Steel?
Entre Pinocchio y Anchor: más estructura que Pinocchio puro, menos peso de macros/IDL que Anchor. Periferalo; no asumas CU gratuitas.
¿Cambiar de framework solucionará el costo de la CPI de Token?
Generalmente no. La CPI de Token y las llamadas al sistema tienen un costo inherente que la elección del framework no puede borrar.
¿Cómo demuestro una ganancia de CU o tamaño?
Simula transacciones idénticas antes y después, registra las CU consumidas p50/p99, compara los tamaños de .so de lanzamiento y bloquea los límites en LiteSVM o CI.
¿Pueden los programas de Anchor y Pinocchio llamarse entre sí?
Sí, a través de CPI cuando las metadatos de cuenta, la propiedad, los layouts y las semillas de PDA coinciden con lo que cada lado espera.
¿Cómo hablan los clientes de Kit con los programas de Pinocchio?
Construye datos de instrucción y metadatos de cuenta a partir de Codama (o codecs manuales). @solana/kit 7.0.0 necesita formatos de cableado correctos, no específicamente Anchor.
¿Cuál es la estrategia de migración más segura?
Congela los layouts y semillas, mueve la ruta crítica detrás de CPI o una actualización controlada, ejecuta en paralelo con pruebas, actualiza los esquemas de cliente, y luego ajusta la autoridad de actualización cuando las métricas y la revisión estén limpias.
¿Cuándo debería un equipo pequeño quedarse en Anchor?
Hasta que el dolor simulado de CU o tamaño sea concreto. El minimalismo prematuro a menudo cuesta más en IDL faltante y errores de validación de lo que ahorra.
¿Cambia la latencia de consenso la elección del framework?
No. El tiempo de confirmación es una preocupación del cliente; la medición de CU y los modelos de cuenta siguen siendo preocupaciones del programa-framework.
¿Qué cadena de herramientas fija esta página?
Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0. Vuelve a evaluar después de las actualizaciones.
¿A dónde debo ir ahora?
Visión General de Frameworks Ligeros, Conceptos Básicos de Pinocchio, Construyendo un Programa con Pinocchio, Framework Steel, Ganancias de CU y Tamaño Binario, y Interoperabilidad y Migración.
Relacionado
- Visión General de Frameworks Ligeros - por qué los equipos miran más allá de Anchor para la eficiencia
- Conceptos Básicos de Pinocchio - punto de entrada, cuentas y patrones mínimos
- Construyendo un Programa con Pinocchio - despacho, validación y estructura de CPI
- Framework Steel - punto intermedio ergonómico entre Pinocchio y Anchor
- Ganancias de CU y Tamaño Binario - cómo medir ganancias reales de eficiencia
- Interoperabilidad y Migración - límites de CPI y movimiento entre pilas
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.