Модель стоимости CPI и синхронизация данных

Модель стоимости CPI

Затраты на CPI списываются из общего вычислительного бюджета транзакции (общий счетчик). Полная формула стоимости для каждого 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

Детализация затрат

Пример расчёта стоимости

CPI с 100 байтами instruction data, 5 account meta, 5 account info (каждый с 1 000 байт данных), SIMD-0339 активен:

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

Синхронизация данных аккаунта

Состояние аккаунта синхронизируется между вызывающей и вызываемой стороной в двух точках во время CPI. Это обеспечивает обеим сторонам согласованный доступ к данным аккаунта.

Пред-CPI синхронизация (от вызывающего к вызываемому)

Перед выполнением вызываемой стороны, update_callee_account копирует текущие изменения вызывающего в представление аккаунта вызываемого:

Пост-CPI синхронизация (от вызываемого к вызывающему)

После возврата вызываемой стороны, update_caller_account копирует изменения вызываемого обратно в представление вызывающего. Это выполняется только для аккаунтов, отмеченных как доступные для записи:

Ограничения на перераспределение памяти

Данные аккаунта могут быть изменены по размеру во время CPI до MAX_PERMITTED_DATA_INCREASE = 10 240 байт (10 КиБ) сверх длины данных аккаунта на начало текущей инструкции верхнего уровня. Это ограничение применяется как в update_callee_account (до CPI), так и в update_caller_account (после CPI). Превышение этого лимита приводит к возврату InvalidRealloc.

Подпись PDA

Когда вызывается invoke_signed, рантайм вычисляет адреса PDA из предоставленных seed и ID программы вызывающего. Это происходит в translate_signers_rust:

1. Массив seed для подписанта проверяется: максимум MAX_SIGNERS (16) наборов seed для подписанта.
2. Каждый набор seed проверяется: максимум MAX_SEEDS (16) seed в наборе, каждый seed не более MAX_SEED_LEN (32) байт.
3. Pubkey::create_program_address вызывается с seed и ID программы вызывающего (а не вызываемой).
4. Если seed не дают валидный PDA (т.е. полученная точка лежит на кривой ed25519), CPI завершится с ошибкой BadSeeds.
5. Полученные PDA pubkey собираются и передаются в prepare_next_instruction как валидные подписанты. При проверке привилегий, если аккаунт вызываемого помечен как подписант и его pubkey совпадает с одним из этих полученных PDA, проверка подписи проходит.

Возврат данных

Программы могут возвращать данные вызывающему с помощью механизма возврата данных. Для этого используются два системных вызова:

• sol_set_return_data: Устанавливает до MAX_RETURN_DATA (1 024) байт возвращаемых данных для текущей инструкции. Стоимость — data_len / cpi_bytes_per_unit + syscall_base_cost CU.
• sol_get_return_data: Читает возвращаемые данные, установленные последней выполненной инструкцией. Возвращает данные вместе с ID программы, которая их установила. Стоимость — (data_len + 32) / cpi_bytes_per_unit + syscall_base_cost CU (32 байта для ID программы).

Данные возврата сохраняются для каждой транзакции и перезаписываются каждой инструкцией, которая вызывает sol_set_return_data. В начале каждого вызова программы runtime сбрасывает данные возврата в пустое значение. После возврата CPI вызывающая сторона может прочитать те данные возврата, которые последними были установлены вызываемой программой (или любой программой, которую она вызвала).