Blueprint de Estudos de Caso

Estudos de caso e builds de referência na Solana são artefatos de aprendizado estruturados: uma forma de problema conhecida, um grafo concreto de contas e instruções, portões operacionais e resultados mensuráveis. Use-os para transferir padrões para seu programa, cliente e runbook de lançamento - não como produtos para fazer fork cegamente.

Esta seção contém três tipos de artefatos: builds de referência (programa DeFi + dApp, lançamento de token SPL, mint de cNFT), estudos antes/depois (CU/aluguel e landing) e conhecimento de falhas (retrospectivas de segurança mais um catálogo de lições). Esta página mapeia como usar esses artefatos como um único sistema de aprendizado - não um resumo de cada irmão.

Resumo

• Trate cada estudo de caso como um loop transferível: moldura do problema → grafo de contas e instruções → cliente e caminho de inclusão → portões de operações e autoridade → medição → captura de lição - então reaplique esse loop ao seu produto com seus pinos de stack.
• Por que Importa: Falhas de produção na Solana raramente vêm de "não saber Rust". Elas vêm de composição incompleta: verificações de signatário ausentes, CU não medida, autoridade de mint deixada ativa, RPC público no dia do mint, ou lições que nunca retornam à revisão de design. Estudos de caso codificam essas costuras em uma forma que você pode auditar.
• Conceitos Chave: build de referência, antes/depois, retrospectiva, catálogo de lições, moldura do problema, grafo de contas, portões de operações, resultado mensurável, controle de prevenção, pinos de stack.
• Quando Usar: Arquitetura Greenfield, integração de engenheiros full-stack, preparação para auditoria, checklists de lançamento, revisões de design pós-incidente e escolha de profundidade (referência vs otimização vs segurança).
• Limitações / Trade-offs: Referências são simplificadas; locais mainnet e profundidades de árvore mudam; métricas de uma equipe não são suas linhas de base; retrospectivas ensinam classes de bugs, não receitas de exploit passo a passo; overfitting a um repositório de amostra congela o design do produto.
• Tópicos Relacionados: Programa DeFi + dApp, lançamento de token SPL, mint de cNFT em escala, otimização de CU e aluguel, landing confiável, retrospectivas de segurança, catálogo de lições.

Fundamentos

Um estudo de caso da Solana só é valioso quando torna as restrições explícitas. A cadeia não se importa que seu produto seja um marketplace ou um jogo. Ela se importa com as contas que você passa, os programas em que você faz CPI, quem assina, quanto compute você consome, se o aluguel é pago e se o líder inclui sua transação sob contenção.

Páginas irmãs nesta seção respondem a perguntas diferentes:

  Moldura do problema (intenção + risco)
           |
           v
  +---------------------------+
  | Forma de Referência       |  contas, ix, cliente, testes
  +-------------+-------------+
                |
                v
  +---------------------------+
  | Medição                   |  CU, aluguel, taxa de landing, custo
  +-------------+-------------+
                |
                v
  +---------------------------+
  | Endurecimento             |  classe de segurança + portões de operações
  +-------------+-------------+
                |
                v
  Entrada no catálogo de lições + controle de CI

Builds de referência ensinam composição (layout, PDAs, cliente de kit, simular-then-send, autoridade). Estudos antes/depois ensinam evidências (linha de base, mudança, remensuração). Retrospectivas ensinam modelos de ameaça. O catálogo é memória de longo prazo para que as armadilhas não retornem como histórias únicas no Slack.

A regra: extraia princípios, rededuzca para suas restrições, prove com testes e métricas. Copiar pastas de monorepo sem rededuzir verificações de conta, taxas e autoridade é cargo-culting.

Mecânicas e Interações

Como ler um build de referência

Trabalhe uma página de referência em quatro passes, não em um skim.

1. Moldura do problema. Qual intenção do usuário está on-chain (depósito, mint, lançamento, inventário em escala)? O que está deliberadamente fora do escopo (legal, valores mobiliários, risco total do local)?
2. Grafo de contas e instruções. Quais contas de propriedade do programa, mints, ATAs, PDAs e programas externos aparecem? O que deve ser gravável vs somente leitura?
3. Caminho do cliente. Como @solana/kit (ou CLI) constrói, simula, assina e confirma? Onde aparecem valores bigint, ambiente de cluster e versão do IDL?
4. Portões de operações. Autoridade de upgrade multisig, política de autoridade de mint/freeze, plano de RPC, verificação de explorador, hash do artefato de release.

Somente após esses quatro passes você deve abrir o deep-dive irmão para detalhes linha a linha. A referência é o mapa; outras seções possuem a teoria.

Superfícies de referência nesta seção

Use cada referência para uma habilidade de composição diferente:

• Referência: Um Programa DeFi + dApp - monorepo, Anchor, LiteSVM, Next.js + kit, autoridade de pausa e deploy; mantenha o estado on-chain e a simulação/envio alinhados.
• Referência: Um Lançamento de Token SPL - mint, metadados, matemática de distribuição, revogação de autoridade; portões de operações irreversíveis que o marketing não pode anular.
• Referência: Um Mint de Compressed-NFT em Escala - capacidade da árvore, Bubblegum, DAS, batching e taxas; trade-offs de custo e inventário que contas NFT comuns escondem.

Não mescle esses em um único "aplicativo modelo". Eles compartilham regras de runtime, não grafos de produto.

Como ler um antes/depois

Páginas antes/depois treinam disciplina de medição.

1. Capture uma linha de base sob um stack e carga de trabalho nomeados (bench LiteSVM, tempo p95 para confirmado, taxa de landing).
2. Mude um subsistema por vez quando possível (reescrita de instrução quente, oráculo de taxa, ALT, RPC privado).
3. Remensura com o mesmo harness.
4. Mantenha um guarda de regressão (bench em CI, alerta de dashboard de landing).

• Antes/Depois: Otimizando um Programa para CU & Aluguel - profile primeiro; zero-copy e frameworks mais leves apenas onde os caminhos quentes os justificam.
• Antes/Depois: Tornando Transações Confiáveis para Landing - landing como métrica de produto; taxas de prioridade, ALTs, estratégia de confirmação, Jito opcional.

Números ilustram o método, não suas garantias. Reexecute as linhas de base em seus pinos (padrão do site: Agave 4.1.1, Anchor 0.32.1, Rust 1.91.1, @solana/kit 7.0.0) antes de reivindicar uma vitória.

Como ler retrospectivas de segurança

Retrospectivas mapeiam classes de exploit para mecânicas Sealevel: verificações de signatário ou proprietário ausentes, substituição de conta, ordem de CPI, frescor do bloco, concentração de privilégio. Leia-as como prompts de modelo de ameaça:

  Classe de incidente público
        |
        v
  Qual verificação estava ausente ou fora de ordem?
        |
        v
  Quais de nossas instruções compartilham essa forma?
        |
        v
  Teste LiteSVM (ou bankrun) que falha sem a correção
        |
        v
  ID do catálogo + checkbox de revisão de design

Use Retrospectivas de Incidentes de Segurança para anatomia e padrões de resposta (pausa, snapshot, patch, verificação, comunicação). Não as trate como tutoriais de ataque; prevenção e testes de regressão são o produto.

Como usar o catálogo de lições

O Catálogo de Lições Aprendidas é o índice, não uma narrativa. Cada entrada deve conter severidade, área (programa / cliente / ops), uma armadilha de uma linha, um ponteiro de prevenção (documento + CI) e uma fonte (incidente, auditoria, data).

Hábitos operacionais que tornam o catálogo real:

• Abra a revisão de design com "algum hit do catálogo nesta superfície de instrução?"
• Após cada auditoria ou quase-acidente, adicione ou atualize um ID antes de fechar o ticket.
• Separe lições de programa, cliente e ops para que o proprietário correto possua o controle.
• Vincule a prevenção a uma página e a uma verificação automatizada quando possível (teste de restrição de signatário, portão de hash de IDL, limite de taxa em rotas de mint).

Uma passagem de aprendizado por toda a seção

Um loop prático de equipe para um novo recurso:

1. Escolha a referência mais próxima (forma DeFi, operações de token ou mint em escala).
2. Preencha a planilha de quatro passes (moldura, contas, cliente, ops).
3. Puxe as expectativas de CU, aluguel e landing das páginas antes/depois para os critérios de aceitação.
4. Modele ameaças com classes de retrospectiva; adicione testes falhos para seus caminhos.
5. Adicione ou marque entradas do catálogo; envie apenas quando os controles de prevenção existirem.

Esse loop é o blueprint. Os artigos irmãos são combustível para os passos 1-4; o catálogo é a memória do passo 5.

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

Escolhendo profundidade por risco

Checklist de transferência (use em todo estudo)

Copie isso em revisões de design; preencha a partir do estudo de caso, não da memória.

• Pinos de stack: Agave/CLI, Anchor, Rust, kit, hash de IDL.
• Grafo de contas: proprietários, signatários, PDAs, mints, IDs de programas externos.
• Modos de falha: falha na simulação, falha no landing, multi-tx parcial, pausa.
• Economia: aluguel, taxas de prioridade/gorjetas, modelo de custo de árvore ou conta.
• Autoridade: mint, freeze, upgrade, pause, atualização de metadados.
• Prova: IDs de teste LiteSVM ou de integração; hash de explorador ou release para ops.
• IDs de Lição: referências novas ou existentes no catálogo.

Antipadrões ao usar estudos de caso

• Fazer fork de um monorepo de referência e enviar sem rededuzir as restrições.
• Tratar porcentagens de antes/depois como SLAs sem re-benchmarking.
• Estudar exploits sem adicionar um teste falho que bloqueie a correção.
• Entradas no catálogo sem proprietários ou ganchos de CI (apodrecimento de wiki).
• Otimizar CU antes que a instrução esteja correta e autorizada.
• Planejar um mint de 100k em RPC público sem política de taxa de prioridade, porque a receita do caminho feliz funcionou em devnet.

Como estudos de caso se relacionam com o resto do site

Seções de teoria (contas, PDAs, segurança, solução de problemas de produção, integrações DeFi) possuem os mecanismos. Esta seção possui composições trabalhadas e loops de feedback. Quando uma referência menciona pausa, ALTs ou revogação de mint, siga o deep dive vinculado para a regra; mantenha o estudo de caso como a narrativa ponta a ponta e a história de medição.

Equívocos Comuns

• "Um build de referência é um produto que devo enviar." É uma forma de ensino. Seu mercado, custódia e restrições de conformidade ainda exigem um design completo.
• "Se eu ler todos os estudos de caso uma vez, estou pronto para produção." A prontidão é rededuzir grafos, testes, métricas e controles de catálogo em suas instruções.
• "Números de antes/depois transferem entre programas." Cargas de trabalho, tamanhos de conta e congestionamento diferem. O método transfere; porcentagens brutas não.
• "Retrospectivas de segurança são apenas para auditores." Todo engenheiro que escreve uma instrução que move valor é responsável pela classe de falha correspondente.
• "O catálogo de lições é documentação opcional." Sem ele, a mesma Signer ausente ou a reexecução de blockhash obsoleto retorna sob um novo título de ticket.
• "Landing e CU são tópicos de infraestrutura, não material de estudo de caso." Na Solana, eles são qualidade e custo visíveis pelo usuário; as páginas antes/depois existem por esse motivo.
• "Lançamentos de cNFT e token SPL são o mesmo problema de ops." Temas compartilhados (autoridade, taxas, RPC) residem em modelos de conta e indexação diferentes; use a referência correspondente.
• "Código do cliente não precisa de entradas de lições." Valores de float, cluster errado, derivação de IDL e taxa de prioridade zero são falhas recorrentes do cliente com as mesmas tags de severidade que bugs de programa.

FAQs

Relacionados

• Referência: Um Programa DeFi + dApp - composição de programa Anchor, testes e cliente kit
• Referência: Um Lançamento de Token SPL - mint, metadados, distribuição, revogação de autoridade
• Referência: Um Mint de Compressed-NFT em Escala - árvores, Bubblegum, DAS, custo em escala
• Antes/Depois: Otimizando um Programa para CU & Aluguel - redução medida de caminho quente e aluguel
• Antes/Depois: Tornando Transações Confiáveis para Landing - taxas, ALTs, confirmação, Jito opcional
• Catálogo de Lições Aprendidas - armadilhas recorrentes com ponteiros de prevenção

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