CPI-Kostenmodell und Datensynchronisation

CPI-Kostenmodell

CPI-Kosten werden aus demselben Transaktions-Rechenbudget gezogen (gemeinsamer Zähler). Die vollständige Kostenformel für jeden invoke / invoke_signed Aufruf:

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

Kostenaufschlüsselung

Beispiel für Kostenberechnung

Ein CPI mit 100 Bytes instruction data, 5 Account-Metas, 5 Account-Infos (jeweils mit 1.000 Bytes Daten), SIMD-0339 aktiv:

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

Synchronisierung von Kontodaten

Der Kontostatus wird zwischen Aufrufer und Aufgerufenem an zwei Punkten während eines CPI synchronisiert. Dies stellt sicher, dass beide Seiten eine konsistente Ansicht der Kontodaten sehen.

Pre-CPI-Synchronisierung (Aufrufer zu Aufgerufenem)

Bevor der Aufgerufene ausgeführt wird, kopiert update_callee_account die laufenden Änderungen des Aufrufers in die Kontoansicht des Aufgerufenen:

Post-CPI-Synchronisierung (Aufgerufener zu Aufrufer)

Nachdem der Aufgerufene zurückkehrt, kopiert update_caller_account die Änderungen des Aufgerufenen zurück in die Ansicht des Aufrufers. Dies erfolgt nur für Konten, die als beschreibbar markiert sind:

Realloc-Limits

Kontendaten können während CPI bis zu MAX_PERMITTED_DATA_INCREASE = 10.240 Bytes (10 KiB) über die Datenlänge des Kontos zu Beginn der aktuellen Top-Level-Instruktion hinaus vergrößert werden. Dieses Limit wird sowohl in update_callee_account (vor CPI) als auch in update_caller_account (nach CPI) durchgesetzt. Bei Überschreitung wird InvalidRealloc zurückgegeben.

PDA-Signierung

Wenn invoke_signed aufgerufen wird, leitet die Runtime PDA-Adressen aus den bereitgestellten Seeds und der Programm-ID des Aufrufers ab. Dies geschieht in translate_signers_rust:

1. Das Signer-Seed-Array wird validiert: maximal MAX_SIGNERS (16) Signer-Seed-Sets.
2. Jedes Seed-Set wird validiert: maximal MAX_SEEDS (16) Seeds pro Set, jeder Seed maximal MAX_SEED_LEN (32) Bytes.
3. Pubkey::create_program_address wird mit den Seeds und der Programm-ID des Aufrufers (nicht des Aufgerufenen) aufgerufen.
4. Wenn die Seeds keine gültige PDA erzeugen (d. h. der resultierende Punkt liegt auf der ed25519-Kurve), schlägt der CPI mit BadSeeds fehl.
5. Die abgeleiteten PDA-Pubkeys werden gesammelt und an prepare_next_instruction als gültige Signer übergeben. Während der Berechtigungsprüfung wird, wenn ein Callee-Konto als Signer markiert ist und sein Pubkey mit einer dieser abgeleiteten PDAs übereinstimmt, die Signer-Prüfung bestanden.

Rückgabedaten

Programme können Daten mithilfe des Rückgabedaten-Mechanismus an Aufrufer zurückgeben. Dieser verwendet zwei Syscalls:

• sol_set_return_data: Legt bis zu MAX_RETURN_DATA (1.024) Bytes an Rückgabedaten für die aktuelle Instruktion fest. Die Kosten betragen data_len / cpi_bytes_per_unit + syscall_base_cost CUs.
• sol_get_return_data: Liest die Rückgabedaten, die von der zuletzt ausgeführten Instruktion festgelegt wurden. Gibt die Daten zusammen mit der Programm-ID zurück, die sie festgelegt hat. Die Kosten betragen (data_len + 32) / cpi_bytes_per_unit + syscall_base_cost CUs (32 Bytes für die Programm-ID).

Rückgabedaten werden pro Transaktion gespeichert und von jeder Anweisung überschrieben, die sol_set_return_data aufruft. Zu Beginn jedes Programmaufrufs setzt die Runtime die Rückgabedaten auf leer zurück. Nachdem ein CPI zurückkehrt, kann der Aufrufer alle Rückgabedaten lesen, die der Aufgerufene (oder ein vom Aufgerufenen aufgerufenes Programm) zuletzt gesetzt hat.