Modelo de custo de CPI e sincronização de dados

Modelo de custo de CPI

Os custos de CPI são retirados do mesmo orçamento computacional da transação (medidor partilhado). A fórmula de custo completa para cada chamada invoke / invoke_signed:

total_cpi_cost = invocation_cost
               + instruction_data_cost
               + account_meta_cost          (SIMD-0339 only)
               + account_info_cost          (SIMD-0339 only)
               + per_account_data_cost      (for each non-executable account)
               + callee_execution_cost

Discriminação de custos

Exemplo de cálculo de custo

Uma CPI com 100 bytes de instruction data, 5 metadados de conta, 5 informações de conta (cada uma com 1.000 bytes de dados), SIMD-0339 ativo:

invocation_cost        = 946
instruction_data_cost  = 100 / 250 = 0  (integer division)
account_meta_cost      = (5 * 34) / 250 = 0
account_info_cost      = (5 * 80) / 250 = 1
per_account_data_cost  = 5 * (1000 / 250) = 20
total (before callee)  = 967 CUs

Sincronização de dados da conta

O estado da conta é sincronizado entre o chamador e o chamado em dois pontos durante uma CPI. Isso garante que ambos os lados vejam uma visão consistente dos dados da conta.

Sincronização pré-CPI (chamador para chamado)

Antes da execução do chamado, update_callee_account copia as modificações em andamento do chamador para a visão da conta do chamado:

Sincronização pós-CPI (chamado para chamador)

Após o retorno do chamado, update_caller_account copia as modificações do chamado de volta para a visão do chamador. Isso só é executado para contas marcadas como graváveis:

Limites de realloc

Os dados da conta podem ser redimensionados durante CPI até MAX_PERMITTED_DATA_INCREASE = 10.240 bytes (10 KiB) além do comprimento dos dados da conta no início da instrução de nível superior atual. Este limite é aplicado tanto em update_callee_account (pré-CPI) quanto em update_caller_account (pós-CPI). Excedê-lo retorna InvalidRealloc.

Assinatura PDA

Quando invoke_signed é chamado, o runtime deriva endereços PDA a partir das seeds fornecidas e do ID do programa do chamador. Isto acontece em translate_signers_rust:

1. O array de seeds de assinante é validado: no máximo MAX_SIGNERS (16) conjuntos de seeds de assinante.
2. Cada conjunto de seeds é validado: no máximo MAX_SEEDS (16) seeds por conjunto, cada seed com no máximo MAX_SEED_LEN (32) bytes.
3. Pubkey::create_program_address é chamado com as seeds e o ID do programa do chamador (não o do chamado).
4. Se as seeds não produzirem um PDA válido (ou seja, o ponto resultante está na curva ed25519), o CPI falha com BadSeeds.
5. As pubkeys PDA derivadas são coletadas e passadas para prepare_next_instruction como assinantes válidos. Durante a verificação de privilégios, se uma conta do chamado estiver marcada como assinante e sua pubkey corresponder a um desses PDAs derivados, a verificação de assinante passa.

Dados de retorno

Os programas podem passar dados de volta aos chamadores usando o mecanismo de dados de retorno. Isto usa duas syscalls:

• sol_set_return_data: Define até MAX_RETURN_DATA (1.024) bytes de dados de retorno para a instrução atual. O custo é data_len / cpi_bytes_per_unit + syscall_base_cost CUs.
• sol_get_return_data: Lê os dados de retorno definidos pela instrução executada mais recentemente. Retorna os dados juntamente com o ID do programa que os definiu. O custo é (data_len + 32) / cpi_bytes_per_unit + syscall_base_cost CUs (32 bytes para o ID do programa).

Os dados de retorno são armazenados por transação e são substituídos por cada instrução que chama sol_set_return_data. No início de cada invocação de programa, o runtime redefine os dados de retorno para vazio. Após um CPI retornar, o chamador pode ler quaisquer dados de retorno que o chamado (ou qualquer programa que o chamado tenha chamado) definiu por último.