Μοντέλο κόστους 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 bytes instruction data, 5 account metas, 5 account infos (το καθένα με 1.000 bytes δεδομένων), με ενεργό το 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 αντιγράφει τις τροποποιήσεις του καλούμενου πίσω στην προβολή του καλούντος. Αυτό εκτελείται μόνο για λογαριασμούς που έχουν επισημανθεί ως εγγράψιμοι:

Όρια realloc

Τα δεδομένα λογαριασμού μπορούν να αλλάξουν μέγεθος κατά τη διάρκεια CPI έως και MAX_PERMITTED_DATA_INCREASE = 10.240 bytes (10 KiB) πέρα από το μήκος δεδομένων του λογαριασμού κατά την έναρξη της τρέχουσας εντολής ανώτατου επιπέδου. Αυτός ο περιορισμός επιβάλλεται τόσο στο update_callee_account (προ-CPI) όσο και στο update_caller_account (μετά-CPI). Η υπέρβασή του επιστρέφει InvalidRealloc.

Υπογραφή PDA

Όταν καλείται το invoke_signed, το runtime παράγει διευθύνσεις PDA από τα παρεχόμενα seeds και το program ID του καλούντος. Αυτό συμβαίνει στο translate_signers_rust:

1. Ο πίνακας signer seeds επικυρώνεται: το πολύ MAX_SIGNERS (16) σύνολα signer seed.
2. Κάθε σύνολο seed επικυρώνεται: το πολύ MAX_SEEDS (16) seeds ανά σύνολο, κάθε seed το πολύ MAX_SEED_LEN (32) bytes.
3. Καλείται το Pubkey::create_program_address με τα seeds και το program ID του καλούντος (όχι του καλούμενου).
4. Εάν τα seeds δεν παράγουν έγκυρο PDA (δηλαδή, το προκύπτον σημείο βρίσκεται στην καμπύλη ed25519), το CPI αποτυγχάνει με BadSeeds.
5. Τα παραγόμενα PDA pubkeys συλλέγονται και μεταβιβάζονται στο prepare_next_instruction ως έγκυροι υπογράφοντες. Κατά τον έλεγχο προνομίων, εάν ένας λογαριασμός καλούμενου επισημαίνεται ως υπογράφων και το pubkey του ταιριάζει με ένα από αυτά τα παραγόμενα PDAs, ο έλεγχος υπογράφοντος περνάει επιτυχώς.

Δεδομένα επιστροφής

Τα προγράμματα μπορούν να μεταβιβάσουν δεδομένα πίσω στους καλούντες χρησιμοποιώντας τον μηχανισμό δεδομένων επιστροφής. Αυτό χρησιμοποιεί δύο syscalls:

• sol_set_return_data: Ορίζει έως και MAX_RETURN_DATA (1.024) bytes δεδομένων επιστροφής για την τρέχουσα εντολή. Το κόστος είναι data_len / cpi_bytes_per_unit + syscall_base_cost CUs.
• sol_get_return_data: Διαβάζει τα δεδομένα επιστροφής που ορίστηκαν από την πιο πρόσφατα εκτελεσμένη εντολή. Επιστρέφει τα δεδομένα μαζί με το program ID που τα όρισε. Το κόστος είναι (data_len + 32) / cpi_bytes_per_unit + syscall_base_cost CUs (32 bytes για το program ID).

Τα δεδομένα επιστροφής αποθηκεύονται ανά συναλλαγή και αντικαθίστανται από κάθε εντολή που καλεί το sol_set_return_data. Στην αρχή κάθε κλήσης προγράμματος, το runtime επαναφέρει τα δεδομένα επιστροφής σε κενά. Αφού επιστρέψει ένα CPI, ο καλών μπορεί να διαβάσει όποια δεδομένα επιστροφής όρισε τελευταίος ο καλούμενος (ή οποιοδήποτε πρόγραμμα κάλεσε ο καλούμενος).