> 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/tr/temel-kavramlar/compute-budget.md). # Hesaplama Bütçesi Rome EVM işlemleri için Solana compute unit (CU) maliyetleri — atomik ve yinelemeli bütçeler ve CU açısından verimli Solidity sözleşmeleri nasıl tasarlanır. Her Solana işleminin, Compute Units (CU) cinsinden ölçülen bir hesaplama bütçesi vardır. CU maliyetlerini anlamak, verimli Rome sözleşmeleri tasarlamanıza yardımcı olur. ## Bütçe Genel Görünümü | Mod | Maksimum CU | Notlar | | ----------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Atomik (VmAt) | \~1,400,000 CU | Tek bir Solana işlemi | | Yinelemeli (VmIt) | Her aşama için en fazla \~1,400,000 CU; oturum başına en fazla 160 yineleme | Her aşama kendi Solana işlemidir; uyarlanabilir opcode'lar/adım — her tx'nin CU bütçesine sığdırılır | Her Solana işleminin varsayılan bütçesi 200,000 CU'dur; compute budget talimatlarıyla \~1,4M CU'ya kadar genişletilebilir (Rome SDK tarafından otomatik olarak eklenir). Yinelemeli yürütme sınırsız değildir. Bir oturum 160 yinelemeden sonra sona erer ve Rust Rome SDK'nın yinelemeli bestecisi en fazla 128 aşama planlar. Cüzdanın kendisinin imzaladığı bir plan şu yoldan geçer `rome_submitSignedV1Plan`; bu, çağrı başına en fazla 64 işlemi kabul eder. Çoğu çağrı çok daha azını gerektirir. Legacy-track CPI'ler yinelemeli bir oturum içinde reddedilir, bu yüzden bunları yapan bir çağrının atomik bütçeye sığması gerekir. Bkz. [Yönlendirilen çağrılar ve uzun çağrılar](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md#relayed-calls-and-long-calls) ve [Kısıtlar](/tr/temel-kavramlar/constraints.md). ## CU Maliyet Tahminleri ### EVM İşlemleri | İşlem | Yaklaşık CU | Notlar | | ------------------------------------------ | -------------------- | ------------------------------------------------------------------------------------------------------------------- | | İşlem imzası kontrolü (EVM anahtarı hattı) | \~25,000 CU | Bu `secp256k1_recover` syscall, aşağıdaki ecrecover ön derlemesiyle aynı maliyette `ecrecover` aşağıdaki ön derleme | | Basit transfer | \~50,000-100,000 CU | Sadece bakiye güncellemeleri | | ERC-20 transferi | \~100,000-150,000 CU | SPL ön derleme çağrısını içerir | | Sözleşme dağıtımı (küçük) | \~200,000-400,000 CU | Bytecode boyutuna bağlıdır | | Depolama yazımı (SSTORE) | \~5,000-20,000 CU | Soğuk ve sıcak erişim | ### Ön derleme İşlemleri | Ön derleme | Yaklaşık CU | Notlar | | --------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25,700 CU | | | SHA-256 | Ölçülen 32 baytlık her kelime başına \~257 CU | Buna ek olarak küçük bir sabit maliyet vardır. Program, SHA-256, RIPEMD-160 ve kimlik ön derlemesini, üçü arasında en maliyetlisi olan RIPEMD-160'a göre boyutlandırılmış, kelime başına yaklaşık 2,200 CU'luk ortak bir değerle fiyatlandırır; bu yüzden bir SHA-256 çağrısından kullandığından daha fazlası ücretlendirilir | | BN254 ecAdd | 0 CU'ya yakın | 32 bayt kopyalamaktan daha ucuz | | BN254 ecMul | \~4,200 CU | | | BN254 ecPairing | \~22,000 CU artı çift başına \~12,800 CU | Dört çiftlik bir kontrol yaklaşık 73,000 CU'dur; tek bir atomik işlemin rahatlıkla içindedir | Bu rakamlar, bir testnet dağıtımında bir Solana düğümünden geri okunan hesaplama birimlerini kullanan programın kendi kalibrasyonundan gelir. Bu sayfa için yeniden ölçülmediler; kendi çağrınızı `computeUnitsConsumed`. ## Optimizasyon Teknikleri ### 1. Sıcak Yollar İçin Yul Kullanın Solidity'nin optimize edicisi makul kod üretir, ancak Yul (satır içi assembly) kritik işlemler için CU'yu önemli ölçüde azaltabilir: ```solidity // Önce: ~600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Solidity düzeyindeki işlemler } // Sonra: ~150K CU (Yul optimizasyonu) function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // Doğrudan bellek manipülasyonu, ABI kodlama ek yükünü atla } } ``` ### 2. PDA Türevlerini Önbelleğe Alın PDA türetimi ile `find_program_address` pahalıdır. Türetilmiş PDA'leri her çağrıda hesaplamak yerine sözleşme depolamasında saklayın: ```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. Bilinen Program Kimliklerini Sabitleyin Program kimliklerini depolamadan yüklemeyin — sabitler kullanın: ```solidity // Pahalı: depolamadan okur bytes32 splTokenProgram = storage_program_id; // Ucuz: derleme zamanı sabiti bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. Hesap Sayısını Azaltın Solana işlemi içindeki her hesap, CU ek yükü ekler. Hesap sayısını şu şekilde azaltın: * Hesapları paylaşan işlemleri toplu hâle getirerek * Daha az ara hesap kullanarak * Gereksiz ATA oluşturma kontrollerinden kaçınarak ### 5. Optimizasyon Ayarlarını Kullanın ```typescript // hardhat.config.ts — bir derleme profilinde optimize ediciyi etkinleştir solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` Şununla derleyin `npx hardhat compile --build-profile production`. ## CU Tüketimini Ölçme Kullan `eth_estimateGas` göndermeden önce CU'yu ölçmek için: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \\ 0xCONTRACT "myFunction(uint256)" 42 ``` Veya ethers.js ile: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("Tahmini gas:", gas.toString()); ``` ## Sırada Ne Var * [Kısıtlar](/tr/temel-kavramlar/constraints.md) — sınırların ve limitlerin tam listesi --- # 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/tr/temel-kavramlar/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.