> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/vi/cac-khai-niem-cot-loi/compute-budget.md). # Ngân sách tính toán Chi phí compute unit (CU) của Solana cho các thao tác Rome EVM — ngân sách atomic so với lặp lại và cách thiết kế các hợp đồng Solidity hiệu quả về CU. Mỗi giao dịch Solana đều có một ngân sách tính toán được đo bằng Đơn vị Tính toán (CU). Hiểu chi phí CU giúp bạn thiết kế các hợp đồng Rome hiệu quả. ## Tổng quan ngân sách | Chế độ | CU tối đa | Ghi chú | | ---------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Nguyên tử (VmAt) | \~1.400.000 CU | Một giao dịch Solana duy nhất | | Lặp (VmIt) | Tối đa \~1.400.000 CU mỗi chặng; tối đa 160 vòng lặp mỗi phiên | Mỗi chặng là một giao dịch Solana riêng; opcode/bước thích ứng — được đóng gói theo ngân sách CU của từng tx | Mỗi giao dịch Solana có ngân sách mặc định là 200.000 CU, có thể mở rộng lên \~1,4 triệu CU thông qua các lệnh ngân sách tính toán (được thêm tự động bởi Rome SDK). Thực thi lặp không phải là vô hạn. Một phiên kết thúc sau 160 vòng lặp, và bộ soạn thảo lặp của Rome SDK bằng Rust lập kế hoạch tối đa 128 chặng. Một kế hoạch do ví tự ký sẽ đi qua `rome_submitSignedV1Plan`, vốn chấp nhận tối đa 64 giao dịch mỗi lần gọi. Hầu hết các lần gọi cần ít hơn nhiều. Các CPI theo track kế thừa bị từ chối trong một phiên lặp, nên một lần gọi tạo ra chúng phải nằm trong ngân sách nguyên tử. Xem [Các lệnh gọi được chuyển tiếp và lệnh gọi dài](/vi/huong-dan-cho-nha-phat-trien/call-evm-from-solana.md#relayed-calls-and-long-calls) và [Ràng buộc](/vi/cac-khai-niem-cot-loi/constraints.md). ## Ước tính chi phí CU ### Các thao tác EVM | Thao tác | CU ước tính | Ghi chú | | ----------------------------------------- | -------------------- | ------------------------------------------------------------------------------------ | | Kiểm tra chữ ký giao dịch (kênh khóa EVM) | \~25.000 CU | Các `secp256k1_recover` syscall, có cùng chi phí với `ecrecover` precompile bên dưới | | Chuyển đơn giản | \~50.000-100.000 CU | Chỉ cập nhật số dư | | Chuyển ERC-20 | \~100.000-150.000 CU | Bao gồm lời gọi precompile SPL | | Triển khai hợp đồng (nhỏ) | \~200.000-400.000 CU | Phụ thuộc vào kích thước bytecode | | Ghi bộ nhớ (SSTORE) | \~5.000-20.000 CU | Truy cập lạnh so với truy cập nóng | ### Các thao tác Precompile | Precompile | CU ước tính | Ghi chú | | --------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25.700 CU | | | SHA-256 | \~257 CU cho mỗi từ 32 byte được đo | Cộng thêm một chi phí cố định nhỏ. Chương trình định giá SHA-256, RIPEMD-160 và precompile identity bằng một mức chung theo mỗi từ khoảng 2.200 CU, được đặt theo RIPEMD-160, loại tốn kém nhất trong ba loại, nên một lời gọi SHA-256 bị tính phí cao hơn mức nó dùng | | BN254 ecAdd | Gần như 0 CU | Rẻ hơn việc sao chép 32 byte | | BN254 ecMul | \~4.200 CU | | | BN254 ecPairing | \~22.000 CU cộng \~12.800 CU cho mỗi cặp | Một phép kiểm tra bốn cặp vào khoảng 73.000 CU, hoàn toàn nằm trong một giao dịch nguyên tử | Các số liệu này đến từ chính hiệu chỉnh của chương trình, sử dụng các đơn vị tính toán được đọc lại từ một node Solana trên triển khai testnet. Chúng không được đo lại cho trang này; hãy tự đo lời gọi của bạn với `computeUnitsConsumed`. ## Các kỹ thuật tối ưu hóa ### 1. Dùng Yul cho các đường nóng Bộ tối ưu của Solidity tạo ra mã khá tốt, nhưng Yul (assembly nội tuyến) có thể giảm CU đáng kể cho các thao tác quan trọng: ```solidity // Trước đây: ~600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Các thao tác ở mức Solidity } // Sau đó: ~150K CU (tối ưu Yul) function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // Thao tác bộ nhớ trực tiếp, bỏ qua chi phí mã hóa ABI } } ``` ### 2. Lưu đệm các phép suy ra PDA Suy ra PDA qua `find_program_address` rất tốn kém. Hãy lưu các PDA đã suy ra trong bộ nhớ hợp đồng thay vì tính lại chúng ở mỗi lần gọi: ```solidity mapping(address => bytes32) private cachedPdas; function getPda(address user) internal returns (bytes32) { bytes32 cached = cachedPdas[user]; if (cached != bytes32(0)) return cached; bytes32 pda = RomeEVMAccount.pda(user); cachedPdas[user] = pda; return pda; } ``` ### 3. Mã cứng các Program ID đã biết Đừng tải Program ID từ bộ nhớ — hãy dùng hằng số: ```solidity // Tốn kém: đọc từ bộ nhớ bytes32 splTokenProgram = storage_program_id; // Rẻ: hằng số tại thời điểm biên dịch bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. Giảm thiểu số lượng tài khoản Mỗi tài khoản trong một giao dịch Solana đều làm tăng chi phí CU. Giảm số lượng tài khoản bằng cách: * Gộp các thao tác dùng chung tài khoản * Dùng ít tài khoản trung gian hơn * Tránh các kiểm tra tạo ATA thừa ### 5. Dùng cài đặt bộ tối ưu ```typescript // hardhat.config.ts — bật bộ tối ưu trong một cấu hình build solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` Biên dịch với `npx hardhat compile --build-profile production`. ## Đo mức tiêu thụ CU Sử dụng `eth_estimateGas` để đo CU trước khi gửi: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \\ 0xCONTRACT "myFunction(uint256)" 42 ``` Hoặc qua ethers.js: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("Gas ước tính:", gas.toString()); ``` ## Tiếp theo là gì * [Ràng buộc](/vi/cac-khai-niem-cot-loi/constraints.md) — danh sách đầy đủ các giới hạn và ranh giới --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/vi/cac-khai-niem-cot-loi/compute-budget.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.