Guia do Solana Anchor Framework

O Solana Anchor Framework ajuda os desenvolvedores a criar programas com validação estruturada de contas, definições de instruções, interfaces geradas e verificações de segurança reutilizáveis.

Nota de versão: As versões do Anchor, Rust, Solana CLI e cliente JavaScript mudam independentemente. Verifique a compatibilidade atual na documentação oficial do Anchor antes de instalar ou implementar. O framework evolui rapidamente.

Este artigo é apenas para fins educacionais e não constitui aconselhamento financeiro ou de investimento. Os investimentos em criptomoedas acarretam riscos significativos. Conduza sempre a sua própria pesquisa antes de tomar decisões de investimento.

📌 NOTA: Este guia utiliza o Anchor v0.29.x e o Solana CLI v1.18.x+, atual em 2024. O Anchor Framework evolui rapidamente. Execute anchor --version para verificar a sua versão instalada antes de seguir estas instruções.

O que é o Solana Anchor Framework?

Índice

1. O que é o Solana Anchor Framework?
2. O Modelo de Contas da Solana
3. Componentes Principais do Solana Anchor Framework
4. Pré-requisitos
5. Como Instalar o Anchor Framework
6. Criar e Implementar o Seu Primeiro Programa Anchor
7. Testar Programas Anchor
8. Anchor vs. Alternativas
9. Segurança do Anchor Framework
10. Resolução de Problemas Comuns em Erros Anchor
11. O Anchor Framework e o Ecossistema de Desenvolvedores da Solana
12. Perguntas Frequentes
13. Conclusão

O que é o Solana Anchor Framework?

O Solana Anchor Framework é um framework de desenvolvimento open-source que elimina o código repetitivo e a complexidade de validação de contas ao escrever programas Solana (o equivalente on-chain a smart contracts) em Rust puro.

Solana é uma blockchain de Camada 1 de alto desempenho que processa aproximadamente 65.000 transações por segundo em condições ótimas (em 2024), com finalidade abaixo de um segundo e taxas geralmente inferiores a $0,001. Solana alcança este throughput parcialmente através de um mecanismo de consenso único chamado Proof of History (PoH), que cria um relógio criptográfico que ordena transações sem a sobrecarga de comunicação dos protocolos de consenso tradicionais.

Criar na Solana sem um framework significa escrever código Rust verboso e de baixo nível para cada programa. Os desenvolvedores devem validar manualmente a propriedade das contas, serializar dados, gerir erros e manter relações de contas para cada transação individual. Para engenheiros vindos de backends Web2 ou desenvolvimento Ethereum, esta barreira de aprendizagem é suficientemente elevada para impedir a maioria dos projetos antes de começarem.

Anchor muda isso. Pense no Anchor como o Ruby on Rails do desenvolvimento Solana: um framework opinativo que trata da infraestrutura para que possa concentrar-se na lógica do seu programa em vez da infraestrutura por baixo dele. O Anchor foi criado por Armani Ferrante e é mantido pela Coral XYZ. Pode encontrar o código fonte e as versões no repositório GitHub do Anchor (coral-xyz/anchor). A versão estável atual é a v0.29.x.

O Anchor permite aos desenvolvedores criar aplicações descentralizadas (dApps). Uma dApp é uma aplicação cuja lógica de backend corre numa blockchain através de programas Solana, em vez de num servidor centralizado. O programa é o backend da dApp; o cliente TypeScript que o Anchor gera é como o seu frontend o chama. As categorias de dApps criadas com o Anchor incluem protocolos de Finanças Descentralizadas (DeFi), plataformas de Tokens Não Fungíveis (NFT), organizações autónomas descentralizadas (DAOs) e jogos Web3.

No final deste guia, compreenderá a arquitetura principal do Anchor, terá um ambiente de desenvolvimento funcional, terá implementado um programa na devnet da Solana (uma rede de teste com SOL gratuito e sem valor), e terá contexto suficiente para avaliar se o Anchor se adequa ao seu projeto. Para uma análise direta de como o Anchor se compara às ferramentas Ethereum e ao desenvolvimento nativo em Rust, consulte como o Anchor se compara ao Hardhat da Ethereum e ao desenvolvimento nativo em Rust.

O que aprenderá:

• O que é Solana e porque a sua arquitetura torna o Anchor necessário
• O que a IDL, macros e PDAs fazem, e como os programas se chamam uns aos outros
• Como instalar o ambiente completo de desenvolvimento Anchor
• Como escrever e implementar o seu primeiro programa Anchor
• Vulnerabilidades de segurança a evitar antes de lançar para a mainnet
• Como resolver os erros mais comuns do Anchor

O Modelo de Contas da Solana: A Base que Precisa de Compreender Primeiro

O modelo de contas da Solana é a base arquitetural que torna o Anchor necessário. É genuinamente diferente de tudo o que encontra no desenvolvimento Ethereum ou Web2. Antes que as abstrações do Anchor façam sentido, precisa de compreender o problema que elas resolvem.

O que é a Solana

Solana é uma rede blockchain de Camada 1 concebida para alto throughput e baixos custos de transação. Ao contrário da Ethereum, que processa aproximadamente 15 a 30 transações por segundo na mainnet, Solana processa aproximadamente 65.000 transações por segundo em condições ótimas (em 2024). As taxas de transação geralmente ficam abaixo de $0,001. Esta combinação de velocidade e custo torna a Solana adequada para aplicações que exigem muitas transações pequenas e frequentes: sistemas de negociação (DeFi), plataformas de minting (NFT) e jogos on-chain.

SOL é o token nativo da Solana. Paga pelas taxas de transação e pelo aluguer que as contas on-chain devem manter para permanecer ativas na rede. Cada programa que implementa e cada conta que o seu programa cria requer SOL para existir on-chain. Na devnet (a rede de teste gratuita da Solana), recebe airdrops de SOL sem custo.

As vantagens de velocidade existem devido a decisões arquiteturais que tornam o desenvolvimento Solana mais difícil do que o desenvolvimento Ethereum ao nível bruto. O Anchor aborda exatamente essas partes difíceis.

Como a Solana Armazena Programas e Dados

Na Solana, "contas" não são contas de utilizador ou carteira nos sentidos habituais. As contas são unidades de armazenamento na blockchain: recipientes distintos que podem conter dados, um saldo de SOL ou código de programa executável.

A distinção arquitetural principal: na Solana, programas (código executável) e dados (estado) residem em contas separadas. Os programas são sem estado. Uma conta de programa contém apenas o bytecode compilado. Os dados residem em contas de dados separadas que os programas leem e para as quais escrevem.

Na Ethereum, um smart contract é como um apartamento autónomo: o código e os móveis vivem no mesmo espaço. Na Solana, um programa é mais como uma empresa com departamentos separados: a lógica executável reside numa conta, e os dados que lê e escreve residem noutras contas completamente diferentes.

Cada conta Solana tem três propriedades: um proprietário (um programa que a controla), um endereço de chave pública (o seu identificador on-chain) e um saldo lamport (a menor unidade de SOL, onde 1 SOL equivale a mil milhões de lamports). As contas de dados também contêm dados de programa serializados.

A consequência prática: quando invoca um programa Solana, tem de fornecer explicitamente todas as contas que o programa lerá ou escreverá. Tem de provar a propriedade. Tem de declarar quais as contas que são mutáveis. Tem de verificar quais as contas que são signatárias. Em Rust puro, esta gestão de contas requer centenas de linhas de código de validação por programa.

Esta gestão explícita de contas é precisamente o problema que o sistema de restrições do Anchor foi concebido para resolver.

Componentes Principais do Solana Anchor Framework: IDL, Macros, PDAs e CPI

O Anchor fornece quatro mecanismos interligados que, em conjunto, eliminam a maior parte da complexidade no desenvolvimento puro de Solana. Compreender cada um deles em sequência é o pré-requisito para escrever o seu primeiro programa.

A IDL (Interface Definition Language): O Contrato de Comunicação do Anchor

O Anchor gera automaticamente um ficheiro JSON chamado Interface Definition Language (IDL) sempre que executa anchor build. Pense nisso como uma especificação OpenAPI para o seu programa on-chain: uma descrição legível por máquina de cada instrução que o seu programa aceita, de cada conta que essas instruções requerem e de cada tipo de dados envolvido.

A IDL é para o Anchor o que uma ABI (Application Binary Interface) é para um contrato Solidity na Ethereum. Se já desenvolveu na Ethereum, sabe como as ABIs permitem que o código front-end chame funções de contrato com segurança de tipo. A IDL do Anchor faz o mesmo para programas Solana, e é gerada automaticamente a partir do seu código Rust. Nunca a escreve à mão.

O ficheiro IDL fica em target/idl/nome_do_seu_programa.json após anchor build. Ao lado dele, o Anchor gera target/types/nome_do_seu_programa.ts, um ficheiro de tipos TypeScript que os seus scripts de front-end ou de teste importam para obter acesso totalmente tipado às instruções do seu programa.

Uma IDL abreviada tem este aspeto:

{
  "version": "0.1.0",
  "name": "balance_tracker",
  "instructions": [
    {
      "name": "initialize",
      "accounts": [
        { "name": "balanceAccount", "isMut": true, "isSigner": false },
        { "name": "user",           "isMut": true, "isSigner": true  },
        { "name": "systemProgram",  "isMut": false, "isSigner": false }
      ],
      "args": []
    },
    {
      "name": "deposit",
      "accounts": [
        { "name": "balanceAccount", "isMut": true, "isSigner": false },
        { "name": "user",           "isMut": false, "isSigner": true }
      ],
      "args": [{ "name": "amount", "type": "u64" }]
    }
  ]
}

O cliente TypeScript lê esta IDL e fornece-lhe chamadas de método totalmente tipadas (program.methods.initialize() e program.methods.deposit(amount)) sem qualquer escrita manual de interface. As suas competências em TypeScript são diretamente aplicáveis aqui.

Macros do Anchor: Como o Anchor Elimina o Código Repetitivo

O Anchor fornece um conjunto de macros Rust, que são geradores de código que escrevem lógica de validação repetitiva para si. Uma macro em Rust é uma anotação que se expande em código no tempo de compilação. As macros do Anchor geram o código de validação de conta, serialização e tratamento de erros que de outra forma escreveria manualmente.

Três macros formam o núcleo de cada programa Anchor:

#[program] marca o módulo que contém as suas funções de tratamento de instruções. O Anchor trata cada função pública neste módulo como uma instrução chamável.

#[derive(Accounts)] gera código de validação de conta a partir de uma definição de struct Rust. Declara quais as contas que uma instrução necessita, e o Anchor gera automaticamente o código para verificar a propriedade e a mutabilidade, bem como o tipo de cada conta.

#[account] marca uma struct como um tipo de dados de conta gerido pelo Anchor e adiciona o discriminador de 8 bytes que permite ao Anchor distinguir o seu tipo de conta de outros.

Veja como estas macros aparecem em contexto:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,           // Anchor cria esta conta (valida que ela não existe)
        payer = user,   // A conta 'user' financia o depósito de isenção de renda
        space = 8 + 8   // Discriminador de 8 bytes + 8 bytes para o campo u64 total
    )]
    pub balance_account: Account<'info, BalanceAccount>,

    #[account(mut)]          // Declara que o saldo lamport desta conta mudará
    pub user: Signer<'info>, // Tipo Signer: Anchor verifica se esta conta assinou a tx

    pub system_program: Program<'info, System>,
}

Restrições de Conta: Como o Anchor Valida Contas Automaticamente

Cada atributo dentro de #[account(...)] é uma restrição do Anchor. As restrições são regras de validação que são executadas automaticamente antes da execução da lógica da sua instrução. São a razão principal pela qual os programas Anchor requerem muito menos código de validação manual do que os programas Rust puros.

As restrições mais comuns são:

#[derive(Accounts)]
pub struct ExampleAccounts<'info> {
    #[account(init, payer = user, space = 8 + 8)]
    // init: cria a conta; reverte se já existir
    pub new_account: Account<'info, MyData>,

    #[account(mut)]
    // mut: declara que os dados ou o saldo lamport desta conta mudarão
    pub existing_account: Account<'info, MyData>,

    #[account(seeds = [b"vault", user.key().as_ref()], bump)]
    // seeds + bump: deriva um endereço PDA e verifica o bump canónico
    pub pda_account: Account<'info, VaultData>,

    #[account(constraint = user_account.authority == user.key())]
    // constraint: avalia uma expressão booleana; falha se for falsa
    pub user_account: Account<'info, UserData>,

    pub user: Signer<'info>,
    // Signer: verifica se a conta assinou a transação
}

Sem restrições, escreveria cada uma destas verificações manualmente no corpo da sua instrução. Com restrições, o Anchor aplica-as antes da execução da lógica da sua instrução. Isto representa tanto um ganho de produtividade como uma funcionalidade de segurança, porque é mais difícil esquecer restrições do que verificações manuais enterradas no código da instrução.

Endereços Derivados de Programa (PDAs): Armazenamento Determinístico On-Chain

Um Endereço Derivado de Programa (PDA) é um dos conceitos mais complicados no desenvolvimento de Solana. Planeie ler esta secção duas vezes. Os PDAs desbloqueiam um dos padrões mais poderosos de Solana, e o Anchor torna-os muito mais geríveis do que Rust puro.

Um PDA é um endereço de conta derivado deterministicamente de um conjunto de sementes (seeds) e de um ID de programa. Ao contrário de um endereço de carteira normal, um PDA não tem uma chave privada correspondente. Nenhum utilizador individual pode assinar por um PDA. Apenas o programa proprietário pode autorizar transações que o envolvam.

Pense num PDA como um cofre de depósito que só o banco (o programa) pode abrir. Nenhum cliente tem a chave; o banco controla o acesso programaticamente. Isto torna os PDAs ideais para cofres controlados por programa, contas escrow e armazenamento específico do utilizador onde o programa, e não o utilizador, deve ter autoridade.

Em Rust puro, derivar um PDA requer chamar Pubkey::find_program_address(&seeds, &program_id) e verificar manualmente o resultado. O Anchor lida com isto com a restrição seeds:

#[derive(Accounts)]
pub struct CreateVault<'info> {
    #[account(
        init,
        payer = authority,
        space = 8 + 32,
        seeds = [b"vault", authority.key().as_ref()], // As seeds determinam o endereço PDA
        bump                 // Anchor encontra e armazena a seed de bump canónica
    )]
    pub vault: Account<'info, Vault>,   // Conta PDA, sem chave privada

    #[account(mut)]
    pub authority: Signer<'info>,

    pub system_program: Program<'info, System>,
}

A restrição seeds diz ao Anchor como derivar o endereço PDA. O campo bump armazena a semente canónica bump, um pequeno inteiro que garante que o endereço derivado sai da curva elíptica e não tem chave privada. No Anchor v0.29.x, o bump canónico é derivado e verificado automaticamente.

Os PDAs são determinísticos: com as mesmas seeds e ID de programa, produzem sempre o mesmo endereço. Esta propriedade permite aos clientes calcular o endereço PDA fora da blockchain para obter dados, enquanto o programa controla o acesso de escrita.

Invocação Cross-Program (CPI): Como os Programas Falam Uns Com os Outros

A Invocação Cross-Program (CPI) é o mecanismo da Solana para um programa chamar as instruções de outro. É o equivalente na blockchain de chamar uma função de biblioteca partilhada. A CPI permite a composabilidade: o seu protocolo DeFi pode chamar o programa SPL Token para transferir tokens, o seu contrato de governança pode chamar um programa de Staking, e assim por diante.

A Solana Program Library (SPL) é o equivalente da Solana a uma biblioteca padrão para programas na blockchain. SPL Token é para a Solana o que ERC-20 é para Ethereum, mas implementado como um programa partilhado na blockchain em vez de um modelo de contrato que cada projeto implementa independentemente. Quando o seu programa Anchor precisa de cunhar ou transferir tokens, chama o SPL Token através de CPI.

O Anchor simplifica as chamadas CPI com o crate anchor-spl e CpiContext:

use anchor_spl::token::{self, Transfer, Token};

pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
    let cpi_accounts = Transfer {
        from: ctx.accounts.vault_token_account.to_account_info(), // Conta de token de origem
        to: ctx.accounts.user_token_account.to_account_info(),   // Conta de token de destino
        authority: ctx.accounts.vault.to_account_info(),         // PDA assina pela vault
    };
    let cpi_ctx = CpiContext::new(ctx.accounts.token_program.to_account_info(), cpi_accounts);
    token::transfer(cpi_ctx, amount)?;  // Chama a instrução de transferência do SPL Token
    Ok(())
}

Sem o Anchor, montar as informações das contas, construir a instrução e chamar invoke_signed requer cerca de 30 linhas. Os helpers de CPI do Anchor reduzem isto a uma chamada de função tipificada e legível.

Colocará estes conceitos em prática em o tutorial passo a passo do programa.

Pré-requisitos: O Que Precisa Antes de Instalar o Anchor Framework

São necessárias quatro ferramentas antes de poder construir com o Anchor Framework na Solana.

Ferramentas necessárias:

1. Rust e Cargo (via rustup), versão 1.70.0 ou posterior recomendada
2. Solana CLI (v1.18.x ou posterior), a ferramenta oficial de linha de comando para interagir com a rede Solana; gere a gestão de carteiras, pedidos de airdrop e configuração de clusters
3. Node.js (v18 ou posterior) mais Yarn ou npm, necessário para o cliente TypeScript e testes Anchor
4. Anchor Version Manager (avm), que instala e gere versões da Anchor CLI; instale sempre o Anchor através do avm em vez de diretamente via Cargo

Em Rust: Os programas Anchor são escritos em Rust. Rust é necessário. Não há como contornar isto. Dito isto, as macros do Anchor abstraem os padrões mais dolorosos do Rust: validação e serialização de contas, mais propagação de erros. Não precisa de um domínio profundo de Rust para construir o seu primeiro programa.

O que precisa para começar: structs, funções, propriedade básica (ownership) e limites de trait a um nível superficial. O que pode adiar para mais tarde: lifetimes, Rust assíncrono (async Rust) e os pontos mais finos do borrow checker. As suas competências em TypeScript ou JavaScript aplicam-se diretamente ao código do lado do cliente do Anchor. Testes, interações de front-end e chamadas de cliente geradas por IDL usam todas TypeScript. Não precisa de ser um especialista em Rust para construir com Anchor, da mesma forma que não precisa de ser um especialista em Ruby para construir com Ruby on Rails. Mas encontrará Rust, e uma familiaridade básica ajuda.

Se a abstração de padrões Rust pelo Anchor lhe interessa, a secção de componentes principais explica o que o Anchor abstrai do Rust em detalhe.

Sobre Solana CLI vs. Anchor CLI: São duas ferramentas separadas com responsabilidades diferentes. A CLI solana gere a interação com a rede: verificar saldos, solicitar airdrops e alternar entre devnet e mainnet. A CLI anchor gere o ciclo de vida do seu programa: inicializar projetos, compilar programas, executar testes e implementar. Ambas são necessárias.

Como Instalar o Anchor Framework: Configuração Passo a Passo

📌 NOTA: Todos os comandos abaixo são validados para Anchor v0.29.x e Solana CLI v1.18.x a partir de 2024. Execute anchor --version após a instalação para confirmar a sua versão. Se estiver a ler isto após a publicação, verifique a versão atual no repositório GitHub do Anchor (coral-xyz/anchor).

Passo 1: Instalar Rust via rustup

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Siga as instruções no ecrã e selecione a instalação padrão
source "$HOME/.cargo/env"
rustc --version
# Deve imprimir: rustc 1.70.0 ou posterior

Passo 2: Instalar a Solana CLI

sh -c "$(curl -sSfL https://release.solana.com/stable/install)"
# Siga as instruções de PATH do output do instalador
solana --version
# Deve imprimir: solana-cli 1.18.x ou posterior

Quando implementa um programa Anchor na Solana, este é armazenado na blockchain e executado pelos nós validadores da rede sempre que uma transação o invoca. A Solana CLI é como interage com esses validadores a partir do seu terminal.

Passo 3: Configurar a Solana CLI para devnet e criar uma carteira

solana config set --url devnet
solana-keygen new
# Cria um par de chaves local (a sua carteira de desenvolvimento)
# Guarde o caminho do output. O Anchor usa este par de chaves para assinar implementações

💡 DICA: Guarde o caminho do seu ficheiro de par de chaves. O Anchor lê este par de chaves a partir da sua configuração Anchor.toml para assinar transações de implementação na devnet.

Passo 4: Solicitar um airdrop de SOL na devnet

solana airdrop 2
solana balance
# Confirme que o saldo mostra 2 SOL

Passo 5: Instalar avm (Anchor Version Manager) e Anchor

cargo install --git https://github.com/coral-xyz/avm avm --locked --force
avm install latest
avm use latest
anchor --version
# Deve imprimir: anchor-cli 0.29.x

📌 NOTA: Instale sempre o Anchor através do avm em vez de diretamente via cargo install anchor-cli. O avm permite-lhe alternar entre versões do Anchor sem reinstalar. Isto é importante quando projetos estão fixados a uma versão específica ou quando está a atualizar um projeto existente.

Passo 6: Inicializar o seu primeiro projeto

anchor init my-first-program
cd my-first-program

Estrutura do seu projeto após anchor init:

my-first-program/
├── Anchor.toml
├── programs/
│   └── my-first-program/
│       └── src/
│           └── lib.rs
├── tests/
│   └── my-first-program.ts
└── app/

💡 DICA: O comando anchor init cria um programa de exemplo funcional em lib.rs. Execute anchor test imediatamente para confirmar que o seu ambiente está a funcionar antes de escrever código próprio.

Construir e Implementar o Seu Primeiro Programa Anchor: Um Guia Completo

Esta secção leva-o de um projeto vazio a um programa implementado na devnet da Solana. O exemplo é um rastreador de Saldo: um programa que inicializa um saldo armazenado a zero e depois aceita instruções de Depósito para o incrementar. Isto demonstra o ciclo de vida completo da conta e é funcionalmente idêntico a um programa contador, mas usa nomes de variáveis originais.

Escrever o Programa Rastreador de Saldo

O seu ficheiro programs/my-first-program/src/lib.rs já contém um andaime (scaffold) do anchor init. Substitua o seu conteúdo pelo seguinte:

// Programa Rastreador de Saldo Anchor v0.29.x
use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkgHH5WfZCnQ");

#[program]
pub mod balance_tracker {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        ctx.accounts.balance_account.total = 0;  // O saldo inicial é zero
        Ok(())
    }

    pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
        ctx.accounts.balance_account.total += amount;  // Incrementa o saldo armazenado
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = user,
        space = 8 + 8   // 8 bytes do discriminador Anchor + 8 bytes para u64
    )]
    pub balance_account: Account<'info, BalanceAccount>,

    #[account(mut)]
    pub user: Signer<'info>,


    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: Signer<'info>,
}

#[account]
pub struct BalanceAccount {
    pub total: u64,
}

Três padrões neste código são importantes antes de prosseguir. Primeiro, #[derive(Accounts)] gera toda a lógica de validação da conta. O Anchor lê a definição da sua struct e escreve as verificações de propriedade, mutabilidade e assinatura. Você declara a intenção; o Anchor impõe. Segundo, space = 8 + 8 aloca exatamente os bytes de que a conta necessita: 8 bytes para o discriminador do Anchor (uma etiqueta única que identifica o tipo de conta e previne ataques de confusão de conta) mais 8 bytes para o total u64. Terceiro, Signer<'info> é o tipo integrado do Anchor que verifica se a conta assinou a transação. Sem ele, qualquer conta poderia chamar a sua instrução de depósito.

Testar o seu Programa com Mocha e TypeScript

Mocha é um executor de testes JavaScript; Chai fornece sintaxe de asserção. Ambos vêm pré-instalados quando executa anchor init. Abra tests/my-first-program.ts e substitua o seu conteúdo:

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { MyFirstProgram } from "../target/types/my_first_program";
import { assert } from "chai";

describe("balance-tracker", () => {
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);

  const program = anchor.workspace.MyFirstProgram as Program<MyFirstProgram>;
  const balanceAccount = anchor.web3.Keypair.generate();

  it("Inicializa uma conta de saldo com total = 0", async () => {
    await program.methods
      .initialize()
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: provider.wallet.publicKey,
        systemProgram: anchor.web3.SystemProgram.programId,
      })
      .signers([balanceAccount])
      .rpc();

    const account = await program.account.balanceAccount.fetch(
      balanceAccount.publicKey
    );
    assert.equal(account.total.toNumber(), 0, "O saldo inicial deve ser 0");
  });

  it("Deposita 500 e atualiza o saldo armazenado", async () => {
    await program.methods
      .deposit(new anchor.BN(500))
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: provider.wallet.publicKey,
      })
      .rpc();

    const account = await program.account.balanceAccount.fetch(
      balanceAccount.publicKey
    );
    assert.equal(account.total.toNumber(), 500, "O saldo deve ser 500 após o depósito");
  });
});

O pacote npm @coral-xyz/anchor é a biblioteca cliente TypeScript do Anchor. O tipo Program<MyFirstProgram> foi gerado automaticamente a partir do IDL quando anchor build foi executado. Este é o valor prático do IDL em ação: o seu código TypeScript obtém segurança de tipo total sobre a interface do seu programa Rust sem qualquer escrita manual de interface.

Este programa é também o back-end de uma dApp. O cliente TypeScript mostrado acima é como uma aplicação front-end o chamaria. Adicione uma UI React ou Next.js acima destas chamadas de método e terá uma aplicação descentralizada completa a correr na Solana.

Construir e Implementar na Devnet

Execute estes três comandos em sequência a partir da raiz do seu projeto:

anchor build
# Saída: target/deploy/my_first_program.so, target/idl/my_first_program.json, target/types/my_first_program.ts

anchor test
# Inicia o validador local, implementa, executa testes Mocha, encerra

anchor deploy --provider.cluster devnet
# A saída inclui o seu ID de Programa: ABC123...xyz789

💡 DICA: Copie o seu ID de Programa da saída de implementação. Atualize o valor declare_id!("...") em lib.rs com ele, e depois execute anchor build novamente para incorporar o endereço correto no seu programa compilado. Atualize também a secção [programs.devnet] em Anchor.toml.

📌 NOTA: Está a implementar na devnet, a rede de testes da Solana. Isto não custa SOL real. O seu airdrop da devnet da secção de configuração cobre a taxa de implementação.

Escreveu e testou um programa Solana, e depois implementou-o usando o Anchor Framework. O programa vive na devnet no seu ID de Programa e executa-se sempre que uma transação o invoca.

Testar Programas Anchor: O Fluxo de Trabalho anchor test

anchor test é um único comando que inicia um validador Solana local, implementa o seu programa nele, executa a sua suite completa de testes Mocha e encerra o validador quando terminar. Não precisa de gerir o validador manualmente.

O fluxo de trabalho de teste em sequência:

1. anchor test lê o seu Anchor.toml para configuração
2. Inicia um processo de validador local em segundo plano
3. Compila e implementa o seu programa nesse validador
4. Executa todos os ficheiros de teste TypeScript no seu diretório tests/ usando Mocha
5. Imprime resultados de sucesso/falha e encerra o validador

Estrutura do ficheiro de teste: Cada ficheiro de teste importa de @coral-xyz/anchor, configura um provedor (que se conecta ao validador local) e referencia o seu programa através do objeto de espaço de trabalho gerado pelo IDL. Os blocos describe e it são sintaxe padrão do Mocha.

Buscar dados da conta: Após chamar uma instrução, busque a conta na blockchain para afirmar o seu estado:

const account = await program.account.balanceAccount.fetch(
  balanceAccount.publicKey
);
assert.equal(account.total.toNumber(), 0);

Testar casos de erro: Teste que entradas inválidas falham corretamente. Um programa bem testado inclui testes negativos:

it("Rejeita depósito de uma conta não assinada", async () => {
  const badActor = anchor.web3.Keypair.generate();
  try {
    await program.methods
      .deposit(new anchor.BN(100))
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: badActor.publicKey,
      })
      .rpc();
    assert.fail("A transação deveria ter sido rejeitada");
  } catch (err) {
    assert.ok(err, "Anchor rejeitou a transação não assinada");
  }
});

Localnet vs. devnet: Use anchor test (localnet) para todo o desenvolvimento ativo. O Localnet é instantâneo e gratuito, e reinicia entre as execuções. Implemente na devnet apenas quando quiser partilhar um URL persistente ou testar contra condições reais da rede.

Mocha é o executor de testes (a estrutura de blocos describe e it). Chai fornece a sintaxe de asserção (assert.equal, assert.ok, expect). Ambos estão pré-configurados em cada projeto anchor init e não requerem instalação separada.

Anchor vs. Alternativas: Escolher o Seu Caminho de Desenvolvimento na Solana

Existem três caminhos de desenvolvimento para construir na Solana: o Anchor Framework, Rust nativo sem framework e Seahorse. A própria Solana é uma das várias blockchains a serem avaliadas para o seu projeto. As tabelas abaixo apresentam as principais diferenças sem defesa.

Tabela 1: Abordagens de Desenvolvimento na Solana

Tabela 2: Ferramentas Solana vs. Ethereum

Quando escolher Anchor em vez de Rust nativo: Para muitos casos de uso de desenvolvimento de aplicações Solana, incluindo protocolos DeFi, plataformas NFT, sistemas de token-gating, DAOs e jogos on-chain, Anchor é um ponto de partida comum. A redução de código repetitivo é substancial: um programa que requer 300 linhas em Rust bruto pode precisar de 80 linhas com Anchor. O desenvolvimento em Rust nativo faz sentido quando um programa requer controlo preciso sobre o consumo de unidades de computação, quando as abstrações de Anchor entram em conflito com uma arquitetura incomum, ou quando uma equipa tem conhecimento profundo de Rust e necessita de flexibilidade máxima.

O Framework Seahorse: Seahorse permite que os desenvolvedores escrevam programas Solana em Python, que o Seahorse compila para Rust compatível com Anchor por baixo do capô. Isto reduz a barreira linguística para desenvolvedores Python que querem experimentar Solana sem aprender Rust. A desvantagem é a maturidade: Seahorse é um projeto comunitário com uma base de utilizadores muito menor do que Anchor e não é recomendado para aplicações de produção em 2024. Para prototipagem é uma opção razoável; para produção, Anchor continua a ser o padrão de facto.

Ethereum vs. Solana: Ethereum oferece o maior ecossistema de desenvolvedores de contratos inteligentes, o histórico mais profundo de auditorias de segurança e o suporte de ferramentas mais amplo. Solana oferece um débito substancialmente mais alto e taxas mais baixas, tornando-a mais adequada para aplicações onde a frequência de transações e o custo são restrições primárias. Estas plataformas servem perfis de aplicação diferentes. Desenvolvedores que constroem infraestrutura de negociação de alta frequência ou jogos de micro-transações podem preferir Solana; desenvolvedores que constroem sistemas de governação ou padrões de token que necessitam de compatibilidade máxima com o ecossistema podem preferir Ethereum. Para a maioria das aplicações de produção em Solana, Anchor é um ponto de partida comum, confirmado por protocolos importantes incluindo Raydium, Marinade Finance e Metaplex que escolheram Anchor como base.

Segurança do Framework Anchor: Cinco Vulnerabilidades Que Todo Desenvolvedor Solana Deve Conhecer

⚠️ AVISO: Vulnerabilidades de segurança em programas Solana podem resultar na perda permanente e irreversível de fundos do utilizador. Antes de implementar qualquer programa em mainnet, execute-o através de uma ferramenta de análise estática como Soteria e considere uma auditoria de segurança profissional. O ecossistema Solana tem sofrido explorações significativas precisamente das vulnerabilidades descritas abaixo. A revisão de segurança não é opcional para programas de produção. Para leituras mais aprofundadas, consulte a documentação oficial do Anchor.

O sistema de restrições do Anchor, os atributos #[account(...)] nas suas estruturas de conta, é a sua primeira linha de defesa de segurança. Ele impõe automaticamente verificações de propriedade, permissões de mutabilidade e verificação de tipo que, de outra forma, escreveria manualmente em Rust bruto. Mas as restrições apenas protegem o que você declara. As vulnerabilidades abaixo surgem do que os desenvolvedores esquecem de declarar.

Falta de Verificação de Assinante

Qualquer conta pode invocar a sua instrução se o chamador não for obrigado a assinar a transação. Isto permite que qualquer carteira chame instruções que deveriam ser restritas.

// VULNERÁVEL: AccountInfo não verifica se o chamador assinou a transação
#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: AccountInfo<'info>,  // Sem verificação de assinatura
}

// SEGURO: Signer<'info> falha a transação se a conta não assinou
#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: Signer<'info>,  // A transação reverte se o utilizador não assinou
}

Utilize Signer<'info> para qualquer conta que deva autorizar uma instrução.

Falta de Verificação de Propriedade (Substituição de Conta)

Um atacante pode substituir uma conta maliciosamente criada que tenha o mesmo layout de dados da sua conta esperada, mas que é propriedade de um programa diferente.

// VULNERÁVEL: AccountInfo não verifica o proprietário do programa da conta
pub balance_account: AccountInfo<'info>,

// SEGURO: Account<'info, T> verifica se a conta é propriedade do seu programa
pub balance_account: Account<'info, BalanceAccount>,  // Verificação de propriedade é automática

Utilize sempre o invólucro tipificado Account<'info, T> do Anchor em vez de AccountInfo<'info> bruto para contas que contêm dados controlados pelo programa.

Ataque de Reinicialização

Se uma instrução initialize puder ser executada mais de uma vez na mesma conta, um atacante pode redefinir um estado que deveria ser permanente.

// VULNERÁVEL: init_if_needed aceita silenciosamente contas já inicializadas
#[account(init_if_needed, payer = user, space = 8 + 8)]
pub balance_account: Account<'info, BalanceAccount>,

// SEGURO: init reverte se a conta já existir
#[account(init, payer = user, space = 8 + 8)]
pub balance_account: Account<'info, BalanceAccount>,

Utilize init (não init_if_needed) para contas que devem ser criadas apenas uma vez. Se init_if_needed for genuinamente necessário, adicione uma bandeira de inicialização explícita e verifique-a na sua lógica de instrução.

Overflow e Underflow de Inteiros

A aritmética do Rust entra em pânico em caso de overflow em compilações de depuração, mas envolve silenciosamente em compilações de lançamento, o que pode corromper saldos financeiros sem gerar um erro.

// VULNERÁVEL: aritmética direta envolve silenciosamente no modo de lançamento
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<() {
    ctx.accounts.balance_account.total += amount;
    Ok(())
}

// SEGURO: checked_add retorna um Err em vez de envolver em caso de overflow
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<() {
    ctx.accounts.balance_account.total = ctx.accounts.balance_account.total
        .checked_add(amount)
        .ok_or(error!(ErrorCode::Overflow))?;
    Ok(())
}

Utilize checked_add, checked_sub e checked_mul para toda a aritmética em valores financeiros. Defina uma enum ErrorCode personalizada com uma variante Overflow para mensagens de erro claras.

Canonicalização de Bump PDA

Usar uma seed de bump não canónica pode produzir um endereço PDA válido, mas inesperado, permitindo ataques de spoofing de endereço.

// VULNERÁVEL: o ajuste manual não é garantido como canónico
#[account(seeds = [b"vault", user.key().as_ref()], bump = ctx.accounts.vault.bump)]
pub vault: Account<'info, Vault>,

// SEGURO: omita o valor explícito do ajuste. Anchor v0.29.x deriva e verifica
// o ajuste canónico automaticamente
#[account(
    seeds = [b"vault", user.key().as_ref()],
    bump,
)]
pub vault: Account<'info, Vault>,

No Anchor v0.29.x, omita o valor explícito do ajuste e deixe o Anchor derivar o ajuste canónico. Se armazenar o ajuste nos dados da conta, preencha-o durante init utilizando ctx.bumps.vault.

Para mensagens de erro que encontrar ao implementar estes padrões de segurança, consulte a secção de resolução de problemas.

Resolução de Problemas de Erros Comuns do Anchor

Os erros abaixo representam os problemas mais comuns que os programadores encontram ao construir com o Anchor Framework. Cada entrada inclui a mensagem de erro exata, a causa e a correção.

📌 NOTA: Incompatibilidades de versão causam a maioria das falhas em anchor build. Verifique esta tabela primeiro antes de investigar outras causas.

Erro 1: AccountNotInitialized

AnchorError causado pela conta: balance_account.
Error Code: AccountNotInitialized.
Error Number: 3012.

Causa: O seu programa tentou ler uma conta de dados que ainda não existe na blockchain. A instrução initialize não foi chamada.

Correção: Chame a sua instrução initialize antes de qualquer instrução que leia a partir da conta. Nos testes, certifique-se de que o bloco it de inicialização é executado antes do bloco de teste de depósito.

Erro 2: Incompatibilidade de Tipo no anchor build

error[E0308]: mismatched types
expected struct `anchor_lang::prelude::AccountInfo`
found struct `anchor_lang::accounts::signer::Signer`

Causa: O seu código usa a sintaxe de restrição de conta do Anchor v0.26.x ou anterior, que mudou no v0.29.x.

Correção: Verifique a documentação oficial do Anchor) para a sintaxe de restrição do v0.29.x. Execute avm use 0.29.0 para confirmar que a sua versão da CLI corresponde à dependência do seu Cargo.toml.

Erro 3: Incompatibilidade entre o Anchor e a CLI Solana

Error: RPC response error -32002: Transaction simulation failed

Causa: A sua versão da CLI Anchor e a versão da CLI Solana são incompatíveis.

Correção:

avm use 0.29.0
solana --version     # Confirme que a CLI Solana é 1.18.x ou posterior

Erro 4: Mismatch de declare_id! Após Redeploy

Error: Program Id mismatch

Causa: Redeployou para um novo endereço, mas declare_id!() em lib.rs ainda mantém o ID do programa antigo.

Correção:

anchor keys sync
anchor build

Erro 5: Fundos Insuficientes na Devnet

Error: Transaction simulation failed: insufficient funds

Causa: A sua carteira devnet não tem SOL suficiente para pagar a taxa de deploy ou transação.

Correção:

solana airdrop 2
solana balance

Erro 6: Binário do Programa Excede o Limite de Tamanho

Error: account data too small for instruction

Causa: O binário do seu programa compilado excede o limite de tamanho de programa da Solana para programas atualizáveis.

Correção: Adicione otimizações de release ao seu Cargo.toml:

[profile.release]
opt-level = "z"
lto = true

Remova dependências e flags de funcionalidades não utilizadas do seu Cargo.toml e Anchor.toml.

Se estiver a encontrar erros de versão, regresse a o guia de instalação e verifique se as suas versões de ferramentas correspondem à tabela de compatibilidade acima.

O Anchor Framework e o Ecossistema de Programadores da Solana

O Anchor Framework potencia a maioria dos programas de produção implementados na mainnet da Solana, incluindo protocolos em Finanças Descentralizadas (DeFi), infraestrutura NFT, e governança on-chain.

Protocolos de produção construídos com Anchor:

• Raydium: Market Maker automatizado (AMM) e protocolo de liquidez
• Marinade Finance: Protocolo de staking líquido para SOL
• Metaplex: padrão NFT, metadados de token e conjunto de ferramentas
• Drift Protocol: Exchange descentralizada de perpétuos
• Kamino Finance: Protocolo de liquidez e empréstimos
• Jito: Staking consciente de MEV e infraestrutura de validadores

Protocolos DeFi representam a categoria dominante de programas implementados com Anchor. Exchanges descentralizadas, plataformas de empréstimos e agregadores de rendimento dependem do throughput da Solana (aproximadamente 65.000 transações por segundo em condições ótimas, a partir de 2024) e das baixas taxas (tipicamente abaixo de $0,001 por transação) para as suas operações principais. O crescimento de instrumentos financeiros on-chain e a tokenização de ativos do mundo real na Solana refletem esta maturidade da infraestrutura.

De acordo com o Relatório de Desenvolvedores da Electric Capital (disponível em electriccapital.com para dados atuais), a base de programadores ativos da Solana cresceu ano após ano até 2023 e em 2024. A crescente adoção por programadores contribui geralmente para a saúde do ecossistema blockchain, embora isto não deva ser interpretado como aconselhamento de investimento.

SOL serve como a moeda de taxa da rede Solana. Cada transação que invoca um programa on-chain custa uma pequena quantidade de SOL (negociável em grandes exchanges de criptomoedas, incluindo Coinbase e Binance). Para dados de mercado atuais de SOL, consulte preço atual e dados de mercado de SOL no CoinGecko.)

Mais programadores a construir com Anchor significa mais programas implementados, o que significa maior utilização da rede Solana. Esta ligação é uma observação sobre a dinâmica do ecossistema, não um sinal de investimento.

Perguntas Frequentes sobre o Anchor Framework da Solana

Que linguagem de programação utiliza a Solana?

Os programas Solana são escritos em Rust. O runtime também suporta C e C++, mas Rust é o padrão para desenvolvimento de produção. Para código do lado do cliente, incluindo testes, interações de front-end e scripts que chamam os seus programas, TypeScript e JavaScript são usados através do pacote npm @coral-xyz/anchor. O Anchor Framework cobre ambas as camadas: Rust para a lógica do programa e TypeScript para tudo o que interage com ele.

É necessário Rust para usar o Anchor Framework?

Sim. Os programas Anchor são escritos em Rust, e não há como contornar isto. Dito isto, as macros do Anchor abstraem as partes mais intensivas em Rust do desenvolvimento Solana: validação de conta e propagação de erros. Um programador com familiaridade básica em Rust (structs, funções, traits, propriedade básica) pode construir e implementar um programa Anchor funcional. Profundo conhecimento de Rust em lifetimes, padrões async e genéricos avançados não é necessário para começar. As suas competências em TypeScript ou JavaScript aplicam-se diretamente ao lado do cliente de todos os projetos Anchor.

O que é um Endereço Derivado do Programa (PDA) em termos simples?

Um Endereço Derivado do Programa (PDA) é um endereço de conta que um programa controla, em vez de um utilizador com uma chave privada. Como os PDAs não têm chave privada, apenas o programa proprietário pode autorizar transações que os envolvam. Dadas as mesmas seeds e ID de programa, um PDA resolve sempre para o mesmo endereço, o que permite aos clientes encontrar contas controladas pelo programa sem armazenar os seus endereços separadamente. O Anchor gere a derivação de PDA automaticamente através da restrição seeds nas suas structs de conta. PDAs são comumente usados para vaults controlados por programa, contas de custódia e armazenamento de dados por utilizador.

É possível construir NFTs com o Anchor Framework?

Sim. A maioria da infraestrutura de NFT da Solana é construída sobre o Anchor. O padrão Metaplex, que define metadados de token, estrutura de coleção e royalties para NFTs da Solana, é em si um programa baseado em Anchor. Qualquer plataforma de NFT na Solana interage com os programas da Metaplex através de Invocação Cross-Program (CPI) usando a crate anchor-spl, que fornece wrappers type-safe para instruções SPL Token.

O Anchor Framework é mantido ativamente?

Sim. O Anchor é mantido pela Coral XYZ e é o padrão de facto para o desenvolvimento de programas Solana em 2024. A versão estável atual é a v0.29.x. O repositório GitHub do Anchor (coral-xyz/anchor) recebe lançamentos regulares que acompanham as atualizações do tempo de execução do Solana. Os principais protocolos de produção, incluindo Raydium, Marinade Finance e Metaplex, continuam a ser desenvolvidos em Anchor, confirmando a sua prontidão para produção.

Como o Anchor se compara ao Hardhat da Ethereum?

O Anchor e o Hardhat desempenham papéis análogos nas suas respetivas blockchains: ambos fornecem andaimes de projetos, um ambiente de testes e ferramentas de implementação. As diferenças começam com a arquitetura subjacente. O Hardhat foca-se no modelo de contrato com estado da Ethereum, onde um Smart Contract detém tanto a sua lógica como o seu estado. O Anchor foca-se no modelo de programa sem estado do Solana, onde programas e dados residem em contas separadas. As linguagens também diferem: projetos Hardhat usam Solidity para contratos e JavaScript ou TypeScript para testes; projetos Anchor usam Rust para programas e TypeScript para testes. Os custos das transações também diferem substancialmente: as transações Solana custam tipicamente menos de $0.001, enquanto as taxas de gas da Ethereum variam e podem atingir $1 a $50 ou mais por transação. Para uma comparação completa lado a lado, consulte as tabelas de comparação Anchor vs. Alternativas.

Quanto tempo demora a aprender o Anchor Framework?

Um programador com experiência em TypeScript ou JavaScript e sem conhecimento prévio de Rust consegue tipicamente construir e implementar um programa Anchor básico na devnet em um a dois dias, utilizando um guia estruturado. Passar de um programa básico para um protocolo DeFi de produção leva semanas a meses, dependendo da complexidade do programa e da profundidade em Rust. A curva de aprendizagem de Rust é a variável principal. Desenvolvedores que investem tempo nos fundamentos de Rust juntamente com o Anchor observam progresso mais rápido em programas não triviais.

A Solana Program Library (SPL) é uma coleção de programas pré-implementados e auditados no Solana para operações comuns. O programa SPL Token é o equivalente do Solana ao padrão ERC-20, implementado como um programa partilhado na blockchain em vez de um modelo de contrato que cada projeto implementa independentemente. O Anchor integra-se com a SPL através do crate anchor-spl, que fornece wrappers type-safe para instruções SPL Token, incluindo transfer, mint_to e burn. A SPL é também a base para metadados de tokens NFT através do programa Metaplex.

Proof of History (PoH) é um mecanismo criptográfico de contagem de tempo que o Solana usa para ordenar transações antes de chegarem aos validadores para consenso. Em vez de exigir que os validadores comuniquem para concordar com a ordem das transações, o PoH incorpora uma sequência de carimbos de data/hora verificáveis diretamente na blockchain. Isto reduz a sobrecarga de coordenação de protocolos de consenso tradicionais e é uma razão pela qual o Solana atinge aproximadamente 65.000 transações por segundo em condições ideais em 2024.

O Solana é adequado para aplicações onde a taxa de transferência de transações e o custo são restrições primárias: protocolos DeFi de alta frequência, mercados NFT com muitas transações pequenas e jogos on-chain. O seu modelo de contas requer mais aprendizagem inicial do que a Ethereum, mas o Anchor Framework reduz significativamente esse atrito. Se o Solana é a escolha certa depende do perfil da sua aplicação. A Ethereum oferece um ecossistema maior e um histórico de auditoria de segurança mais estabelecido, enquanto o Solana oferece taxas mais baixas e maior taxa de transferência para casos de uso que beneficiam de ambos.

Conclusão: O Anchor Framework é Adequado para o Seu Projeto Solana?

Para muitos fluxos de trabalho de desenvolvimento de aplicações Solana, o Anchor Framework é um ponto de partida comum, enquanto o Rust nativo permanece relevante quando é necessário um controlo de nível inferior.

O Anchor reduz substancialmente o boilerplate do desenvolvimento Rust bruto. Programas que requerem centenas de linhas em código Rust nativo do Solana levam uma fração disso com o sistema de macros do Anchor. Ele impõe a segurança das contas através do seu sistema de restrições, detetando erros de propriedade e autorização em tempo de compilação ou tempo de execução em vez de em produção. E gera automaticamente um cliente TypeScript a partir do IDL, dando aos programadores JavaScript uma interface tipada e familiar para os seus programas sem escrever Rust no lado do cliente.

O desenvolvimento Rust nativo vale a pena considerar apenas quando o seu programa requer controlo preciso sobre o consumo de unidades de computação ou quando as abstrações do Anchor entram genuinamente em conflito com uma arquitetura invulgar. Para a vasta maioria dos programas, incluindo protocolos DeFi, plataformas NFT, DAOs e sistemas de token-gating, o Anchor é onde deve começar.

Próximos passos:

1. Implemente o programa de rastreamento de Saldo deste guia na devnet usando anchor deploy --provider.cluster devnet
2. Explore a documentação oficial do Anchor em anchor-lang.com para a referência completa da API e funcionalidades avançadas
3. Consulte o repositório de exemplos do GitHub do Anchor para programas com padrões de produção
4. Junte-se ao Discord do Anchor ou ao Solana Stack Exchange para suporte comunitário quando encontrar problemas

O programa que implementou neste guia é real: vive na devnet do Solana, aceita transações e armazena estado na blockchain. Essa é a base em que todas as aplicações de produção do Solana são construídas.

Guias Técnicos Relacionados do Solana

• Endereços de contrato Solana e IDs de Programa
• Padrões de Token Solana
• Tokens SPL Solana

Os programadores que acompanham o SOL juntamente com as ferramentas do ecossistema podem consultar a página de preço do SOL) como uma referência de mercado separada; não valida a segurança do programa ou a prontidão da implementação.