Instruction Arguments
Argumentos após Context<T> são serializados com Borsh nos dados da instrução. Use #[instruction(...)] na struct de contas para referenciar args em constraints.
Receita
#[derive(Accounts)]
#[instruction(amount: u64, recipient: Pubkey)]
pub struct Transfer<'info> { /* use amount in constraint */ }
pub fn transfer(ctx: Context<Transfer>, amount: u64, recipient: Pubkey) -> Result<()> {
require!(amount > 0, MyError::InvalidAmount);
Ok(())
}Quando usar: Clientes passam parâmetros numéricos ou pubkeys além da lista de contas.
Exemplo Prático
#[derive(Accounts)]
#[instruction(id: u64)]
pub struct CreatePool<'info> {
#[account(
init,
payer = payer,
space = 8 + Pool::INIT_SPACE,
seeds = [b"pool", id.to_le_bytes().as_ref()],
bump,
)]
pub pool: Account<'info, Pool>,
#[account(mut)]
pub payer: Signer<'info>,
pub system_program: Program<'info, System>,
}
pub fn create_pool(ctx: Context<CreatePool>, id: u64, fee_bps: u16) -> Result<()> {
require!(fee_bps <= 10_000, PoolError::InvalidFee);
ctx.accounts.pool.fee_bps = fee_bps;
Ok(())
}O que isso demonstra:
- Ordem dos args no handler corresponde à serialização do cliente
#[instruction]expõe args para constraints- Valide intervalos com
require!cedo - Args Pubkey frequentemente duplicam chaves de conta para seeds de PDA
Aprofundamento
Serialização
O Anchor antepõe um discriminator de instrução de 8 bytes, depois codifica args com Borsh na ordem dos parâmetros do handler.
Dicas de validação
- Rejeite amounts zero e pubkeys sentinela.
- Mantenha a lista de args pequena para reduzir CU e bugs no cliente.
- Prefira contas em vez de args quando a pubkey deve assinar ou manter dados.
Erros comuns
- Ordem de args divergente no cliente - Deserialização falha.. Correção: Gere clientes a partir do IDL.
- #[instruction] ausente na struct - Não é possível usar args em seeds.. Correção: Adicione o atributo com os mesmos nomes.
- Confiar em args em vez de contas - Pubkey em arg não vinculada a signer.. Correção: Exija conta Signer correspondente.
- Vec grande em args - Explosão de CU e tamanho.. Correção: Use remaining_accounts ou padrão de upload separado.
- Overflow de fee ou amount - Matemática sem checagem no handler.. Correção: Use
checked_add/checked_mul.
Alternativas
| Alternativa | Use quando | Não use quando |
|---|---|---|
| API só com contas | Quando toda entrada é estado on-chain | Escalares fornecidos pelo cliente |
| Dados de instrução manualmente (nativo) | Layouts não-Borsh | Fluxos de IDL do Anchor |
| Prefixo de byte de versão em layout customizado | Migração de layout de args | Programas Anchor greenfield |
FAQs
Qual versão do Anchor é assumida?
0.32.1 em toda esta seção.
Uma PDA pode ser Signer na struct de contas?
Não. Use constraints de seeds e assinatura em CPI.
Onde o bump é armazenado?
No campo da struct de conta, definido na inicialização.
Como os clientes derivam PDAs?
Use @solana/kit 7.0.0 com os mesmos bytes de seed.
Qual program id é usado para PDAs?
O endereço declare_id do seu programa Anchor.
Seeds incluem bump?
Não no array de seeds; bump é parâmetro separado em find_program_address.
Como depurar falhas de PDA?
Compare chaves logadas; verifique seeds e program id no client-side.
PDAs são rent-exempt?
Sim quando mantêm dados; financie com payer no init.
Uma PDA pode assinar múltiplos CPIs em uma ix?
Sim, com as mesmas signer seeds em cada CPI.
O que ler em seguida?
Veja os links em Relacionados para tópicos mais profundos sobre args.
Relacionados
- Instruction Handlers - assinaturas
- Seeds & Bump Constraints - args em seeds
- Building Instructions - codificação no cliente
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.