Pinocchio em Profundidade

As estruturas do programa Solana ficam no mesmo tempo de execução: bytecode SBF, metas de conta explícitas, medição de unidade de computação (CU) e CPI. O que muda é a quantidade de validação, codegen e cliente cola que a estrutura gera para você.

Anchor 0.32.1 otimiza a velocidade do desenvolvedor e um pipeline IDL completo. Pinocchio e Steel otimizam para abstrações mais finas, binários menores e controle mais rígido sobre o custo do caminho ativo.

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

Resumo

• Ideia principal: Estruturas leves (Pinocchio, Steel) são kits de ferramentas de estilo nativo mais finos que reduzem a sobrecarga de macro e dependência para que você possa validar contas, instruções de despacho e CPI com menos código gerado do que o Anchor, ao custo de mais segurança manual e trabalho de esquema do cliente.
• Por que é importante: Muitos produtos nunca precisam sair da Anchor; alguns atingem limites máximos de UC, exercem pressão de tamanho ou auditam preferências que recompensam verificações explícitas. Escolher a pilha errada desperdiça meses; escolher o limite certo (ou um limite híbrido de CPI) é uma decisão econômica, não uma disputa de pureza.
• Conceitos principais: Pinocchio, Steel, Anchor, programa nativo, unidades de computação (CU), tamanho binário (.so), IDL / Codama, ponto de entrada, validação manual, interoperabilidade CPI, reescrita de hot-path.
• Quando Usar: Orientar uma equipe sobre opções de framework; justificar uma reescrita com métricas; projetando a periferia da anchor + núcleo do Pinocchio; decidir se o meio-termo de Steel se encaixa; planejar a migração sem quebrar layouts de contas ou clientes.
• Limitações/Compensações: Você perde as macros de restrição do Anchor e a história IDL padrão; a superfície de revisão de segurança cresce; o codegen do cliente se torna um pipeline explícito; os ganhos desaparecem se Token CPI ou syscalls dominarem o orçamento de instrução.
• Tópicos relacionados: Visão geral leve, noções básicas de Pinocchio, programas de construção, vitórias em Steel, CU e tamanho binário, interoperabilidade e migração e quando usar qual estrutura.

Fundações

Um programa Solana ainda é uma conta executável que implementa aproximadamente process_instruction(program_id, accounts, data). As estruturas diferem na fiação do ponto de entrada, nas superfícies AccountInfo e na quantidade de validação e adesão do cliente que elas geram.

Por que existem estruturas leves

O valor do Anchor é real: estruturas de contas, atributos de restrição, erros, eventos e clientes orientados por IDL em @solana/kit 7.0.0. Essa conveniência custa peso de dependência, verificações macro-expandidas e padrões que podem aumentar o tamanho de CU e .so em caminhos estreitos.

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

Eles aparecem quando instruções importantes atingem o orçamento da UC, o tamanho binário ou o aluguel de implantação prejudicam, os auditores preferem verificações explícitas ou um núcleo compartilhado multiplica cada UC salva pelo volume. Eles não existem porque Anchor está errado. Anchor 0.32.1 continua sendo o padrão para a maioria dos programas aplicativos.

Pinocchio vs Anchor (e vs nativo bruto)

Pinocchio é uma caixa Rust mínima para programas de estilo nativo: macro de ponto de entrada, informações de conta, pubkeys, erros e ajudantes de invocação, geralmente com uma pequena árvore e postura amigável ao #![no_std]. Você ainda:

1. Entre por entrypoint!(process_instruction).
2. Analise os dados da instrução (opcode, Borsh ou customizado).
3. Valide signatários, capacidade de escrita, proprietários, PDAs e layout você mesmo.
4. Altere contas e CPI com invoke / invoke_signed.

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

Steel fica entre Pinocchio e Anchor: mais estrutura de instrução/conta do que Pinocchio bruto, menos macro e maquinário IDL do que Anchor. Procure-o quando Pinocchio se sentir muito vazio, mas o perfil de custo do Anchor estiver errado.

CU e tamanho binárioTrabalho de instrução de medidores CU. O tamanho binário é a pegada .so implantada (e a economia da implantação). Pilhas leves podem cortar a cola da estrutura, desencorajar o registro pesado em caminhos quentes e encorajar analisadores rígidos. Eles não podem apagar pisos de syscall, linhas de base SPL Token/Token-2022 CPI ou seu algoritmo.

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

Interoperabilidade, migração e escolha

Os programas interoperam por meio de CPI e bytes de conta compartilhados, não de estruturas compartilhadas. Anchor pode chamar Pinocchio (e reverter) quando metas, proprietários, discriminadores e sementes de PDA concordam. A migração geralmente congela layouts e sementes, move primeiro um caminho ativo, execuções duplas ou 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.

O padrão é ficar no Anchor até que restrições de perfil, tamanho ou auditoria forcem o contrário. Prefira reescritas híbridas em vez de big bang. Pinocchio para núcleos mínimos; Steel para estrutura sem anchor completa; nativo bruto quando a equipe já possui disciplina solana-program completa.

Mecânica e interações

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

  Client (Kit / Codama / hand-built ix)
           |
           v
  Transaction names accounts + program id
           |
           v
  Runtime loads SBF program (.so)
           |
           v
  Entrypoint -> parse ix -> validate accounts
           |
           +--> mutate program-owned data
           +--> CPI to System / Token / others
           |
           v
  CU consumed; success or ProgramError

**Ponto de entrada e expedição.

** Pinocchio parece nativo: uma entrada e, em seguida, combine ou enum descompacte. Steel adiciona estrutura de estilo de registro para programas com múltiplas instruções. Anchor gera despacho a partir do módulo do programa e dos tipos de contas. Todos os três ainda são um ID de programa SBF para o tempo de execução.

**Validação.

** Anchor codifica verificações de signatário, mut, proprietário, sementes e token como atributos. Pinocchio os reimplementa no Rust, de preferência por meio de ajudantes compartilhados. Ignorar verificações para "salvar CU" quase nunca vale a pena: o custo de exploração diminui a economia de cálculo.

**Estado e PDAs.

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

**CPI entre pilhas.

** Formas típicas: Administrador anchor -> Núcleo de assentamento Pinocchio; Pinocchio -> Sistema/Token; Aplicativo Steel -> Programa Ecossistema Anchor. A ordem e a capacidade de escrita da conta devem corresponder ao receptor. As macros da estrutura não alinham automaticamente as listas de CPI entre as caixas.

**Clientes e IDL.

** O ponto forte do Anchor é o IDL em clientes digitados. Pinocchio e Steel precisam de Codama (ou codecs feitos à mão). @solana/kit 7.0.0 não se importa com qual estrutura construiu o .so; ele precisa de formatos de fio corretos. Trabalho do cliente com orçamento quando você sai da Anchor.

**Medindo vitórias.

**

1. Baseline CU p50/p99 em um gráfico de conta fixa (Surfpool/simular).
2. Reescreva apenas a instrução quente ou extraia um núcleo CPI.
3. Simular novamente entradas idênticas; compare o tamanho da versão .so.
4. Bloqueie tetos CU em LiteSVM/CI.

Se o Token CPI dominar, corrija o algoritmo ou o design da conta antes das estruturas de compra.

Considerações e aplicações avançadas

Arquitetura híbrida

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

Despender esforços de sistemas onde a CU é crítica para o produto; mantenha Anchor onde CU é barato.

Segurança e tamanho além da troca de framework

Sair do Anchor aumenta a superfície de revisão: cada signatário, proprietário, PDA, contas restantes vinculadas e código de erro são de propriedade manual. Invista em auxiliares de validação, testes invariantes e difusão do analisador. Trate a remoção de restrições como um projeto de segurança e não apenas como um projeto de desempenho.

O tamanho também vem de caixas pesadas na cadeia, msg!/formatação em caminhos quentes, serialização duplicada e recursos não utilizados. Fixe os perfis de liberação cargo build-sbf e meça novamente após Agave 4.1.1 / colisões CLI.

Steel, padrões de migração e uma rubrica de decisão

Steel é uma aposta no processo: as convenções reduzem os bugs mais rapidamente do que o minimalismo puro sem o custo total da 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. Perfile steel contra a anchor e o Pinocchio em your quente ix.

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

Pontue aproximadamente 0-2 cada: habilidade de anchor, espaço de CU, pressão binária, necessidade de IDL integrada, cronograma de auditoria, profundidade em Rust de sistemas.

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

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

Equívocos comuns

• "Pinocchio sempre usa menos CU do que Anchor." Frequentemente verdadeiro em caminhos com estrutura pesada, nunca garantido. Syscalls e Token CPI podem dominar; medir txs fixos.
• "Sair do Anchor significa menos verificações de segurança." Você possui todos os cheques que o Anchor usou para gerar. Leve não é segurança mais leve.
• "Devemos reescrever todo o programa." Uma instrução quente ou núcleo CPI geralmente captura a maior parte do ganho com menos risco.- "Steel é inutilizável / Pinocchio está sempre pronto para produção." Ambas são opções de pilha. Fixe as versões da caixa no Agave 4.1.1 e na sua barra de auditoria.
• "Os clientes inventarão o formato wire." Sem IDL ou Codama, os clientes TypeScript apodrecem. Publique esquemas com implantações.
• "O tamanho binário é cosmético." Arquivos .so maiores afetam o custo de implantação e o atrito operacional.
• "A escolha da estrutura substitui o design do algoritmo." Gráficos de contas ruins e CPIs extras perdem para qualquer pilha. Corrija o design quando os perfis assim o indicarem.

Perguntas frequentes

Relacionado

• Visão geral dos frameworks leves - por que as equipes olham além da anchor em busca de eficiência
• Pinocchio Basics - ponto de entrada, contas e padrões mínimos
• Construindo um programa com Pinocchio - despacho, validação e estrutura de CPI
• Steel Framework - meio termo ergonômico entre Pinocchio e Anchor
• CU e vitórias em tamanho binário - como medir ganhos reais de eficiência
• Interop & Migration - Limites de CPI e movimentação entre pilhas

Versões 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.