Runtime de conta

Carregamento de conta

Antes de uma transação ser executada, o runtime carrega todas as contas referenciadas através de load_transaction_accounts(). Este processo realiza várias validações:

1. Validação do pagador de taxas: o pagador de taxas (primeira conta) deve existir, ser uma conta de sistema ou conta nonce, e ter lamports suficientes para cobrir as taxas (validate_fee_payer()). Após pagar as taxas, a conta deve permanecer isenta de renda ou ir para exatamente 0 lamports. Não pode terminar entre 0 e o mínimo de isenção de renda. As contas nonce devem sempre reter lamports suficientes para permanecerem isentas de renda. Se o pagador não for uma conta de sistema nem uma conta nonce, a transação falha com TransactionError::InvalidAccountForFee.

2. Limite de tamanho de dados carregados: o tamanho total de todas as contas carregadas (incluindo um TRANSACTION_ACCOUNT_BASE_SIZE de 64 bytes por conta) não deve exceder MAX_LOADED_ACCOUNTS_DATA_SIZE_BYTES (64 MiB). Exceder este limite produz TransactionError::MaxLoadedAccountsDataSizeExceeded.

3. Validação de program account: cada programa invocado por uma instrução deve existir e ser propriedade de um carregador válido: um dos PROGRAM_OWNERS (BPF Loader Upgradeable, BPF Loader, BPF Loader Deprecated, Loader V4) ou o carregador nativo. Se o program account não existir, a transação falha com TransactionError::ProgramAccountNotFound. Se existir mas tiver um proprietário inválido, a transação falha com TransactionError::InvalidProgramForExecution.

4. Contas inexistentes: Contas que não existem on-chain são carregadas como contas padrão (0 lamports, dados vazios, pertencentes ao System Program) com rent_epoch definido como u64::MAX.

Formato de serialização BPF

Quando um programa é invocado, o runtime serializa as contas num buffer de memória contíguo e passa-o para a BPF VM. O formato de serialização (para o formato alinhado padrão usado por todos os loaders exceto o loader-v1 obsoleto) é definido em serialize_parameters_aligned().

O buffer começa com um u64 (8 bytes, little-endian) contendo o número de contas. Depois, para cada conta na instrução, o buffer contém:

Após todas as contas, o buffer anexa:

Para contas duplicadas, apenas 1 byte (o marcador de duplicação com o índice da original) mais 7 bytes de preenchimento são escritos.

Desduplicação de contas

Quando a mesma chave pública de conta aparece várias vezes no array accounts de uma instrução, o runtime desduplica as mesmas. Cada entrada na lista de contas da instrução obtém sua própria estrutura InstructionAccount, mas entradas que se referem à mesma conta de nível de transação apontam para os mesmos dados subjacentes.

O método is_instruction_account_duplicate determina se um determinado índice de conta de instrução é a primeira ocorrência ou uma duplicação ao procurar o índice de conta de nível de transação e encontrar o primeiro índice de nível de instrução que mapeia para ele:

• Se o índice de conta de instrução atual for igual ao primeiro índice mapeado, ele não é uma duplicação (retorna None).
• Caso contrário, retorna Some(first_index), onde first_index é o índice da primeira ocorrência.

Como todas as referências à mesma conta compartilham o mesmo AccountSharedData subjacente, modificações através de qualquer referência são imediatamente visíveis através de todas as outras referências. No entanto, apenas um empréstimo mutável pode ser mantido de cada vez. Tentar emprestar a mesma conta de forma mutável através de dois diferentes índices de conta de instrução simultaneamente retorna InstructionError::AccountBorrowFailed. Os programas devem liberar um empréstimo antes de adquirir outro na mesma conta subjacente.

Após a execução do programa, o runtime desserializa o buffer de volta (deserialize_parameters_aligned()) e aplica quaisquer alterações a lamports, data (incluindo alterações de comprimento até MAX_PERMITTED_DATA_INCREASE), e owner.