Pinocchio em Profundidade

Os frameworks de programas Solana rodam no mesmo ambiente de execução: bytecode SBF, metadados de conta explícitos, medição de unidades de computação (CU) e CPI. O que muda é quanta validação, geração de código e "cola" de cliente o framework gera para você.

Anchor 0.32.1 otimiza para velocidade de desenvolvimento e um pipeline IDL completo. Pinocchio e Steel otimizam para abstrações mais finas, binários menores e controle mais rigoroso sobre o custo do caminho crítico.

Esta página é o guarda-chuva da seção: por que existem frameworks leves, como Pinocchio e Steel se relacionam com Anchor e o solana-program nativo, como pensar sobre CU e tamanho de binário, como a interoperabilidade e a migração realmente funcionam e quando cada escolha é justificada.

Resumo

• Frameworks leves (Pinocchio, Steel) são toolkits mais enxutos no estilo nativo que reduzem a sobrecarga de macros e dependências para que você possa validar contas, despachar instruções e fazer CPI com menos código gerado do que o Anchor, ao custo de mais trabalho manual de segurança e esquema de cliente.
• Insight: Muitos produtos nunca precisam sair do Anchor; alguns atingem tetos de CU, pressão de tamanho de implantação ou preferências de auditoria que recompensam verificações explícitas. Escolher a stack errada desperdiça meses; escolher a correta (ou um limite híbrido de CPI) é uma decisão econômica, não uma disputa por pureza.
• Conceitos-chave: Pinocchio, Steel, Anchor, programa nativo, unidades de computação (CU), tamanho binário (.so), IDL / Codama, entrypoint, validação manual, interoperabilidade CPI, rewrite de hot-path.
• Quando Usar: Orientar uma equipe sobre opções de framework; justificar uma reescrita com métricas; projetar a periferia do Anchor + núcleo Pinocchio; decidir se o meio-termo do Steel se encaixa; planejar a migração sem quebrar layouts de conta ou clientes.
• Limitações/Compromissos: Você perde as macros de restrição do Anchor e a história padrão de IDL; a superfície de revisão de segurança aumenta; a geração de código do cliente se torna um pipeline explícito; os ganhos desaparecem se Token CPI ou chamadas de sistema dominarem o orçamento de instrução.
• Tópicos Relacionados: Visão geral de frameworks leves, noções básicas de Pinocchio, construção de programas, Steel, ganhos de CU e tamanho de binário, interoperabilidade e migração, e quando usar cada framework.

Fundamentos

Um programa Solana ainda é uma conta executável que implementa aproximadamente process_instruction(program_id, accounts, data). Os frameworks diferem na conexão do entrypoint, nas superfícies de AccountInfo e na quantidade de validação e "cola" de cliente que eles geram.

Por que existem frameworks leves

O valor do Anchor é real: structs de contas, atributos de restrição, erros, eventos e clientes orientados por IDL em @solana/kit 7.0.0. Essa conveniência tem um custo em peso de dependência, verificações expandidas por macros e padrões que podem inflar o tamanho de CU e .so em caminhos críticos.

Frameworks leves respondem a uma questão de produto, não a uma disputa por pureza: podemos manter a correção pagando menos por instrução e por implantação?

Eles surgem quando instruções críticas atingem o orçamento de CU, o tamanho binário ou o custo de implantação incomoda, os auditores preferem verificações explícitas ou um núcleo compartilhado multiplica cada CU salva em volume. Eles não existem porque o Anchor está errado. Anchor 0.32.1 continua sendo o padrão para a maioria dos programas de aplicação.

Pinocchio vs Anchor (e vs nativo bruto)

Pinocchio é um crate Rust minimalista para programas de estilo nativo: macro de entrypoint, informações de conta, pubkeys, erros e auxiliares de invocação, geralmente com uma árvore pequena e postura amigável a #![no_std]. Você ainda:

1. Entra via entrypoint!(process_instruction).
2. Analisa os dados da instrução (opcode, Borsh ou customizado).
3. Valida signatários, capacidade de escrita, proprietários, PDAs e layout você mesmo.
4. Modifica contas e faz CPI com invoke / invoke_signed.

Você não obtém a rede de segurança #[derive(Accounts)] do Anchor. Esse é o ponto e o risco.

Steel fica entre Pinocchio e Anchor: mais estrutura de instrução/conta que o Pinocchio bruto, menos macros e maquinário de IDL que o Anchor. Use-o quando o Pinocchio parecer muito "nu", mas o perfil de custo do Anchor estiver errado.

CU e tamanho binário

CU mede o trabalho de instrução. O tamanho binário é a pegada do .so implantado (e a economia de implantação). Stacks leves podem reduzir a "cola" do framework, desencorajar logs pesados em caminhos críticos e incentivar parsers enxutos. Eles não podem apagar os pisos de syscall, as linhas de base de CPI do SPL Token / Token-2022 ou seu algoritmo.

"Reescrevemos em Pinocchio" não é uma métrica. unitsConsumed simulado em uma transação fixa, mais o tamanho do .so de lançamento, é uma métrica.

Interoperabilidade, migração e escolha

Programas interoperam através de CPI e bytes de conta compartilhados, não de frameworks compartilhados. O Anchor pode chamar Pinocchio (e vice-versa) quando metadados, proprietários, discriminadores e sementes de PDA concordam. A migração geralmente congela layouts e sementes, move primeiro um caminho crítico, executa em paralelo ou usa limites de CPI durante a transição, atualiza Codama/IDL com clientes e, em seguida, reforça a autoridade de atualização após métricas e revisão.

Use Anchor como padrão até que restrições de profiling, tamanho ou auditoria forcem o contrário. Prefira abordagens híbridas em vez de reescritas "big bang". Pinocchio para núcleos mínimos; Steel para estrutura sem Anchor completo; nativo bruto quando a equipe já domina a disciplina completa do solana-program.

Mecânica e Interações

A escolha do framework aparece em entrada/despacho, validação, estado e CPI, e clientes.

  Cliente (Kit / Codama / ix feito à mão)
           |
           v
  Transação nomeia contas + ID do programa
           |
           v
  Runtime carrega programa SBF (.so)
           |
           v
  Entrypoint -> parse ix -> valida contas
           |
           +--> modifica dados de propriedade do programa
           +--> CPI para System / Token / outros
           |
           v
  CU consumida; sucesso ou ProgramError

Entrypoint e despacho. Pinocchio se parece com o nativo: uma entrada, depois match ou desempacotamento de enum. Steel adiciona estrutura estilo registro para programas com múltiplas instruções. Anchor gera o despacho a partir do módulo do programa e dos tipos de conta. Todos os três ainda são um único ID de programa SBF para o runtime.

Validação. Anchor codifica verificações de signer, mut, owner, seeds e token como atributos. Pinocchio as reimplementa em Rust, idealmente através de auxiliares compartilhados. Ignorar verificações para "economizar CU" quase nunca vale a pena: o custo de exploração supera a economia de computação.

Estado e PDAs. Mantenha uma única fonte de verdade para discriminadores, ordem de campos, sementes/bumps de PDA e códigos de erro. Através de limites de CPI ou de migração, bytes e sementes devem corresponder, não apenas nomes conceituais de campos.

CPI entre stacks. Formas típicas: Admin Anchor -> Núcleo de liquidação Pinocchio; Pinocchio -> System/Token; Aplicação Steel -> Programa do ecossistema Anchor. A ordem e a capacidade de escrita da conta devem corresponder ao chamado. Macros de framework não alinham automaticamente listas de CPI entre crates.

Clientes e IDL. O ponto forte do Anchor é o IDL em clientes tipados. Pinocchio e Steel precisam de Codama (ou codecs feitos à mão). @solana/kit 7.0.0 não se importa com qual framework construiu o .so; ele precisa de formatos de comunicação corretos. Orce o trabalho do cliente quando você sair do Anchor.

Medindo ganhos.

1. Baseline de CU p50/p99 em um grafo de conta fixo (Surfpool / simular).
2. Reescreva apenas a instrução crítica ou extraia um núcleo CPI.
3. Simule novamente entradas idênticas; compare o tamanho do .so de lançamento.
4. Trave os tetos de CU em LiteSVM/CI.

Se o Token CPI dominar, corrija o algoritmo ou o design da conta antes de escolher frameworks.

Considerações Avançadas e Aplicações

Arquitetura Híbrida

Reescritas completas são raras. Uma forma comum em produção:

Invista esforço de sistemas onde a CU é crítica para o produto; mantenha o Anchor onde a CU é barata.

Segurança e Tamanho Além da Troca de Framework

Sair do Anchor aumenta a superfície de revisão: cada signer, owner, PDA, limite de remaining_accounts e código de erro é de responsabilidade manual. Invista em auxiliares de validação, testes de invariantes e fuzzing de parsers. Trate a remoção de restrições como um projeto de segurança, não apenas um projeto de performance.

O tamanho também vem de crates pesados on-chain, msg!/formatação em caminhos críticos, serialização duplicada e recursos não utilizados. Perfis de lançamento cargo build-sbf e reavalie após atualizações do Agave 4.1.1 / CLI.

Steel, Padrões de Migração e uma Rubrica de Decisão

Steel é uma aposta de processo: convenções reduzem bugs mais rapidamente do que o minimalismo puro sem o custo total do Anchor. Use-o quando a contagem de instruções for alta, vários programas precisarem de padrões compartilhados e você ainda aceitar IDL externo mais segurança manual. Faça o profiling do Steel contra Anchor e Pinocchio em sua instrução crítica.

Nunca altere layouts casualmente no meio de uma migração sem uma instrução de migração versionada e um plano de cliente.

Pontue aproximadamente 0-2 cada: habilidade com Anchor, margem de CU, pressão de binário, necessidade de IDL embutido, prazo de auditoria, profundidade em Rust de sistemas.

• Baixa pressão de CU/tamanho + forte necessidade de IDL -> Anchor.
• Alta CU/tamanho + Rust forte + Codama disposto -> Pinocchio (ou Steel se a estrutura ajudar).
• Superfície mista -> CPI híbrido.
• Incerto -> Anchor até que a simulação prove dor.

Anexe números de simulação a um ADR curto para que o próximo debate de reescrita comece a partir de dados.

Equívocos Comuns

• "Pinocchio sempre usa menos CU que Anchor." Frequentemente verdadeiro em caminhos com muito framework, nunca garantido. Syscalls e Token CPI podem dominar; meça transações fixas.
• "Sair do Anchor significa menos verificações de segurança." Você é responsável por cada verificação que o Anchor costumava gerar. Leve não significa segurança mais leve.
• "Precisamos reescrever o programa inteiro." Uma instrução crítica ou núcleo CPI geralmente captura a maior parte do ganho com menos risco.
• "Steel é inutilizável / Pinocchio está sempre pronto para produção." Ambos são escolhas de stack. Fixe as versões dos crates no Agave 4.1.1 e na sua barra de auditoria.
• "Os clientes inventarão o formato de comunicação." Sem IDL ou Codama, os clientes TypeScript se deterioram. Publique esquemas com as implantações.
• "Tamanho binário é cosmético." Arquivos .so maiores afetam o custo de implantação e o atrito operacional.
• "A escolha do framework substitui o design do algoritmo." Maus grafos de conta e CPIs extras perdem para qualquer stack. Corrija o design quando os perfis indicarem.

FAQs

Relacionado

• Visão Geral de Frameworks Leves - por que equipes buscam além do Anchor por eficiência
• Noções Básicas de Pinocchio - entrypoint, contas e padrões mínimos
• Construindo um Programa com Pinocchio - despacho, validação e estrutura de CPI
• Framework Steel - meio-termo ergonômico entre Pinocchio e Anchor
• Ganhos de CU e Tamanho de Binário - como medir ganhos reais de eficiência
• Interop & Migração - Limites de CPI e movimentação entre stacks

Versões da Stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.