Modèle de coût CPI et synchronisation des données

Modèle de coût CPI

Les coûts CPI sont prélevés sur le même budget de calcul de transaction (compteur partagé). La formule de coût complète pour chaque appel 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

Répartition des coûts

Exemple de calcul de coût

Un CPI avec 100 octets d'instruction data, 5 métadonnées de compte, 5 informations de compte (chacune avec 1 000 octets de données), SIMD-0339 actif :

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

Synchronisation des données de compte

L'état du compte est synchronisé entre l'appelant et l'appelé à deux moments lors d'un CPI. Cela garantit que les deux parties voient une vue cohérente des données de compte.

Synchronisation pré-CPI (appelant vers appelé)

Avant l'exécution de l'appelé, update_callee_account copie les modifications en cours de l'appelant vers la vue de compte de l'appelé :

Synchronisation post-CPI (appelé vers appelant)

Après le retour de l'appelé, update_caller_account copie les modifications de l'appelé vers la vue de l'appelant. Cela ne s'exécute que pour les comptes marqués comme modifiables :

Limites de realloc

Les données de compte peuvent être redimensionnées pendant un CPI jusqu'à MAX_PERMITTED_DATA_INCREASE = 10 240 octets (10 Kio) au-delà de la longueur des données du compte au début de l'instruction de niveau supérieur actuelle. Cette limite est appliquée à la fois dans update_callee_account (pré-CPI) et update_caller_account (post-CPI). La dépasser renvoie InvalidRealloc.

Signature PDA

Lorsque invoke_signed est appelé, le runtime dérive les adresses PDA à partir des seeds fournies et de l'ID du programme appelant. Cela se produit dans translate_signers_rust :

1. Le tableau de seeds de signataire est validé : au maximum MAX_SIGNERS (16) ensembles de seeds de signataire.
2. Chaque ensemble de seeds est validé : au maximum MAX_SEEDS (16) seeds par ensemble, chaque seed au maximum MAX_SEED_LEN (32) octets.
3. Pubkey::create_program_address est appelé avec les seeds et l'ID du programme appelant (pas celui de l'appelé).
4. Si les seeds ne produisent pas une PDA valide (c'est-à-dire que le point résultant est sur la courbe ed25519), le CPI échoue avec BadSeeds.
5. Les pubkeys PDA dérivées sont collectées et transmises à prepare_next_instruction en tant que signataires valides. Lors de la vérification des privilèges, si un compte appelé est marqué comme signataire et que sa pubkey correspond à l'une de ces PDA dérivées, la vérification du signataire réussit.

Données de retour

Les programmes peuvent transmettre des données aux appelants en utilisant le mécanisme de données de retour. Cela utilise deux syscalls :

• sol_set_return_data : Définit jusqu'à MAX_RETURN_DATA (1 024) octets de données de retour pour l'instruction actuelle. Le coût est de data_len / cpi_bytes_per_unit + syscall_base_cost CU.
• sol_get_return_data : Lit les données de retour définies par l'instruction exécutée le plus récemment. Renvoie les données ainsi que l'ID du programme qui les a définies. Le coût est de (data_len + 32) / cpi_bytes_per_unit + syscall_base_cost CU (32 octets pour l'ID du programme).

Les données de retour sont stockées par transaction et sont écrasées par chaque instruction qui appelle sol_set_return_data. Au début de chaque invocation de programme, le runtime réinitialise les données de retour à vide. Après le retour d'un CPI, l'appelant peut lire les dernières données de retour définies par l'appelé (ou tout programme appelé par l'appelé).