Mô hình chi phí CPI và đồng bộ dữ liệu

Mô hình chi phí CPI

Chi phí CPI được trừ từ cùng một ngân sách tính toán giao dịch (đồng hồ đo chung). Công thức chi phí đầy đủ cho mỗi lần gọi 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

Phân tích chi phí

Ví dụ tính toán chi phí

Một CPI với 100 byte instruction data, 5 account meta, 5 account info (mỗi cái có 1.000 byte dữ liệu), SIMD-0339 đang hoạt động:

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

Đồng bộ hóa dữ liệu tài khoản

Trạng thái tài khoản được đồng bộ hóa giữa caller và callee tại hai thời điểm trong quá trình CPI. Điều này đảm bảo cả hai bên đều thấy một cái nhìn nhất quán về dữ liệu tài khoản.

Đồng bộ trước CPI (caller sang callee)

Trước khi callee thực thi, update_callee_account sao chép các thay đổi đang diễn ra của caller sang chế độ xem tài khoản của callee:

Đồng bộ sau CPI (callee sang caller)

Sau khi callee trả về, update_caller_account sao chép các thay đổi của callee trở lại chế độ xem của caller. Điều này chỉ chạy cho các tài khoản được đánh dấu là writable:

Giới hạn realloc

Dữ liệu tài khoản có thể được thay đổi kích thước trong CPI lên đến MAX_PERMITTED_DATA_INCREASE = 10.240 byte (10 KiB) vượt quá độ dài dữ liệu của tài khoản tại thời điểm bắt đầu lệnh cấp cao nhất hiện tại. Giới hạn này được thực thi trong cả update_callee_account (trước CPI) và update_caller_account (sau CPI). Vượt quá giới hạn này sẽ trả về InvalidRealloc.

Ký PDA

Khi invoke_signed được gọi, runtime sẽ suy ra địa chỉ PDA từ các seed được cung cấp và program ID của caller. Điều này xảy ra trong translate_signers_rust:

1. Mảng signer seed được xác thực: tối đa MAX_SIGNERS (16) bộ signer seed.
2. Mỗi bộ seed được xác thực: tối đa MAX_SEEDS (16) seed trên mỗi bộ, mỗi seed tối đa MAX_SEED_LEN (32) byte.
3. Pubkey::create_program_address được gọi với các seed và program ID của caller (không phải của callee).
4. Nếu các seed không tạo ra PDA hợp lệ (tức là điểm kết quả nằm trên đường cong ed25519), CPI sẽ thất bại với BadSeeds.
5. Các pubkey PDA được suy ra sẽ được thu thập và truyền đến prepare_next_instruction như các signer hợp lệ. Trong quá trình kiểm tra đặc quyền, nếu một tài khoản callee được đánh dấu là signer và pubkey của nó khớp với một trong các PDA được suy ra này, kiểm tra signer sẽ thành công.

Dữ liệu trả về

Các chương trình có thể truyền dữ liệu trả lại cho caller bằng cách sử dụng cơ chế return data. Điều này sử dụng hai syscall:

• sol_set_return_data: Thiết lập tối đa MAX_RETURN_DATA (1.024) byte dữ liệu trả về cho lệnh hiện tại. Chi phí là data_len / cpi_bytes_per_unit + syscall_base_cost CU.
• sol_get_return_data: Đọc dữ liệu trả về được thiết lập bởi lệnh được thực thi gần đây nhất. Trả về dữ liệu cùng với program ID đã thiết lập nó. Chi phí là (data_len + 32) / cpi_bytes_per_unit + syscall_base_cost CU (32 byte cho program ID).

Dữ liệu trả về được lưu trữ theo từng giao dịch và bị ghi đè bởi mỗi lệnh gọi sol_set_return_data. Khi bắt đầu mỗi lần gọi chương trình, runtime đặt lại dữ liệu trả về thành rỗng. Sau khi CPI trả về, bên gọi có thể đọc bất kỳ dữ liệu trả về nào mà bên được gọi (hoặc bất kỳ chương trình nào mà bên được gọi đã gọi) đặt cuối cùng.