> 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/id/konsep-inti/compute-budget.md). # Anggaran Komputasi Biaya satuan komputasi Solana (CU) untuk operasi Rome EVM — anggaran atomik vs. iteratif dan cara merancang kontrak Solidity yang efisien CU. Setiap transaksi Solana memiliki anggaran komputasi yang diukur dalam Compute Units (CU). Memahami biaya CU membantu Anda merancang kontrak Rome yang efisien. ## Ikhtisar Anggaran | Mode | Maks CU | Catatan | | --------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Atomik (VmAt) | \~1,400,000 CU | Satu transaksi Solana | | Iteratif (VmIt) | Hingga \~1,400,000 CU per leg; paling banyak 160 iterasi per sesi | Setiap leg adalah transaksi Solana tersendiri; opcode/langkah adaptif — disesuaikan ke anggaran CU tiap tx | Setiap transaksi Solana memiliki anggaran default 200.000 CU, yang dapat diperluas hingga \~1,4 juta CU melalui instruksi compute budget (ditambahkan secara otomatis oleh Rome SDK). Eksekusi iteratif tidak tak terbatas. Satu sesi berakhir setelah 160 iterasi, dan iterative composer dari Rust Rome SDK merencanakan paling banyak 128 leg. Rencana yang ditandatangani sendiri oleh dompet melewati `rome_submitSignedV1Plan`, yang menerima paling banyak 64 transaksi per panggilan. Sebagian besar panggilan membutuhkan jauh lebih sedikit. CPI jalur legacy ditolak di dalam sesi iteratif, jadi panggilan yang membuatnya harus masuk dalam anggaran atomik. Lihat [Panggilan yang direlai dan panggilan panjang](/id/panduan-pengembang/call-evm-from-solana.md#relayed-calls-and-long-calls) dan [Kendala](/id/konsep-inti/constraints.md). ## Perkiraan Biaya CU ### Operasi EVM | Operasi | CU Perkiraan | Catatan | | ---------------------------------------------------- | -------------------- | --------------------------------------------------------------------------------------------------- | | Pemeriksaan tanda tangan transaksi (jalur kunci EVM) | \~25,000 CU | Panduan `secp256k1_recover` syscall, dengan biaya yang sama seperti `ecrecover` precompile di bawah | | Transfer sederhana | \~50,000-100,000 CU | Hanya pembaruan saldo | | Transfer ERC-20 | \~100,000-150,000 CU | Termasuk panggilan precompile SPL | | Penerapan kontrak (kecil) | \~200,000-400,000 CU | Tergantung pada ukuran bytecode | | Penulisan penyimpanan (SSTORE) | \~5,000-20,000 CU | Akses dingin vs hangat | ### Operasi Precompile | Precompile | CU Perkiraan | Catatan | | --------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25,700 CU | | | SHA-256 | \~257 CU per word 32-byte yang diukur | Ditambah biaya tetap kecil. Program menetapkan harga SHA-256, RIPEMD-160, dan precompile identitas dengan satu angka per-word bersama sekitar 2.200 CU, disesuaikan untuk RIPEMD-160, yang paling mahal di antara ketiganya, sehingga panggilan SHA-256 dikenakan biaya lebih besar daripada yang digunakannya | | BN254 ecAdd | Hampir 0 CU | Lebih murah daripada menyalin 32 byte | | BN254 ecMul | \~4,200 CU | | | BN254 ecPairing | \~22,000 CU ditambah \~12,800 CU per pasangan | Pemeriksaan empat pasangan sekitar 73.000 CU, masih jauh di dalam satu transaksi atomik | Angka-angka ini berasal dari kalibrasi program itu sendiri, yang menggunakan compute units yang dibaca kembali dari node Solana pada deployment testnet. Angka-angka ini tidak diukur ulang untuk halaman ini; ukur panggilan Anda sendiri dengan `computeUnitsConsumed`. ## Teknik Optimisasi ### 1. Gunakan Yul untuk Jalur Kritis Optimizer Solidity menghasilkan kode yang cukup baik, tetapi Yul (inline assembly) dapat mengurangi CU secara signifikan untuk operasi penting: ```solidity // Sebelum: ~600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Operasi tingkat Solidity } // Setelah: ~150K CU (optimisasi Yul) function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // Manipulasi memori langsung, lewati overhead pengodean ABI } } ``` ### 2. Cache Derivasi PDA Derivasi PDA melalui `find_program_address` mahal. Simpan PDA yang telah diturunkan di penyimpanan kontrak daripada menghitungnya pada setiap panggilan: ```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. Hardcode ID Program yang Diketahui Jangan memuat ID program dari penyimpanan — gunakan konstanta: ```solidity // Mahal: membaca dari penyimpanan bytes32 splTokenProgram = storage_program_id; // Murah: konstanta waktu kompilasi bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. Minimalkan Jumlah Akun Setiap akun dalam transaksi Solana menambah overhead CU. Kurangi jumlah akun dengan: * Mengelompokkan operasi yang berbagi akun * Menggunakan lebih sedikit akun perantara * Menghindari pemeriksaan pembuatan ATA yang redundan ### 5. Gunakan Pengaturan Optimizer ```typescript // hardhat.config.ts — aktifkan optimizer dalam profil build solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` Build dengan `npx hardhat compile --build-profile production`. ## Mengukur Konsumsi CU Gunakan `eth_estimateGas` untuk mengukur CU sebelum mengirimkan: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \ 0xCONTRACT "myFunction(uint256)" 42 ``` Atau melalui ethers.js: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("Estimated gas:", gas.toString()); ``` ## Apa Selanjutnya * [Kendala](/id/konsep-inti/constraints.md) — daftar lengkap batas dan pembatasan --- # 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/id/konsep-inti/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.