> 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/constraints.md). # Kısıtlamalar Rome EVM üzerinde geliştirme yaparken sınırlar — Solana işlem boyutu, \~1,4M CU bütçesi, hesap sınırları, depolama düzeni ve Rome'un bunların her birinin etrafından nasıl çalıştığı. Rome EVM üzerinde geliştirme yaparken önemli sınırlar ve kısıtlar. Bu kısıtlamaları anlamak, güvenilir çalışan sözleşmeler tasarlamanıza yardımcı olur. ## Solana İşlem Sınırları | Kısıt | Değer | Etkisi | | -------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------- | | İşlem boyutu | 4 KB (4.096 bayt) | Rome, Solana v1 işlemlerini gönderir; daha büyük EVM işlemleri aracı hesaplarda aşamalı olarak tutulur (şeffaf) | | İşlem başına hesaplama birimleri | \~1,4M CU | Bunu aşan işlemler, aşağıda kendi sınırları olan yinelemeli modu kullanır | | İşlem başına hesaplar | 64 adres | v1 işlem üst sınırı; EVM işleminin ve onun CPI'lerinin dokunduğu her şey, Rome'un kendi hesapları dahil, sayılır | | Maksimum tutucu boyutu | 80 KB | Tek bir EVM işlemi için maksimum RLP boyutu | ## EVM Yürütme Sınırları | Kısıt | Değer | Notlar | | ---------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sözleşme depolama slotları | Depolama hesabı başına 256 | Sözleşme başına birden fazla depolama hesabı oluşturulabilir | | Yineleme başına opcode'lar | Uyarlanabilir | Her Solana işleminin CU bütçesine göre paketlenir (VmIt) | | Hesap kilidi TTL'si | 3 sn (oturum 28'den fazla hesaba dokunduğunda 4 sn) | Yinelemeli yürütme sırasında; her adımda yenilenir | | Yinelemeli oturum uzunluğu | 160 adım | Sınır aşıldığında sonraki adım oturumun kilitlerini serbest bırakır ve hiçbir şey işlemeden sonlandırır | | Rust Rome SDK'sı tarafından planlanan aşamalar | 128 | Yinelemeli oluşturucunun tavan sınırı; gerçek çağrılar çok daha azında sonuçlanır | | Cüzdan imzalı plan başına işlem | 64 | En fazla `rome_submitSignedV1Plan` tek çağrıda kabul eder; bkz. [Yönlendirilen çağrılar ve uzun çağrılar](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md#relayed-calls-and-long-calls) | | Hazine cüzdanları | 64 | Ücret havuzu cüzdanları | | Sözleşme boyut sınırı | 24 KB | Ethereum ile aynı (EIP-170, 24.576 bayt) | ## CPI Kısıtlamaları | Kısıt | Değer | Notlar | | ----------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | CPI derinliği | En fazla 4 seviye | Solana'nın CPI derinlik sınırı | | CPI çağrısı başına hesaplar | 64 adreslik işlem üst sınırı içinde | İşlemin dokunduğu diğer tüm hesaplarla paylaşılır | | CPI + Transfer Hook derinliği | CPI seviyelerini kullanır | CPI içinden yapılan transfer hook'ları derinliği aşabilir | | Sözleşme başına bir iz | Eski (`0xff…07/08/09`, `0x42…16`) **veya** önbelleğe alınmış (`0xff…04/05/06/0b`) | İkisiyle birlikte değiştirici çağrıları tek bir işlemde karıştırmak reddedilir | | Yinelemeli modda legacy CPI | İzin verilmiyor | Yinelemeli bir işlemde legacy-track CPI şu hatayla başarısız olur `CpiProhibitedInIterativeTx`; önbelleğe alınmış-track etkilerine izin verilir | **CPI derinliği en kritik kısıttır.** Solana, Rome programını çağırdığında Rome EVM bir CPI seviyesi tüketir. Solidity sözleşmeniz ardından başka bir Solana programını CPI ile çağırırsa, bu seviye 2'dir. O program bir başkasını çağırırsa, bu seviye 3'tür. Toplamda en fazla 4 seviyeniz vardır. ``` Seviye 0: Solana Runtime → Rome EVM Programı Seviye 1: Rome EVM Programı → CPI hedefiniz (ör. Jupiter) Seviye 2: Jupiter → başka bir program (ör. Raydium) Seviye 3: Raydium → SPL Token (maksimum derinlik) ``` ## Token-2022 Transfer Hook Kısıtlamaları | Kısıt | Etkisi | | --------------------------- | ------------------------------------------------------------------------- | | Her mint için bir hook | Bir Token-2022 mint'i tek bir transfer-hook yuvasına sahiptir | | `transfer_checked` yalnızca | Hook'lar düz `transfer`. Rome köprü işlemleri kullanır `transfer_checked` | | Mint/yakım hook'lu değil | Mint yetkisiyle kontrol edilir, hook'larla değil | ## Gaz ve Fiyatlandırma Kısıtlamaları | Kısıt | Notlar | | ------------------------- | ---------------------------------------------------------------------- | | Gaz fiyatlandırma kaynağı | Meteora DAMM havuzu, v1 veya v2 (SPL gaz tokeni) | | Gaz fiyat çarpanı | Proxy başına yapılandırılabilir (`gas_price_mul`) | | Minimum gaz fiyatı | Proxy yapılandırması tarafından belirlenir | | Gaz tahmini | Gönderimden önce Mollusk emülatörü aracılığıyla zincir dışında yapılır | ## Ağa Özgü Kısıtlamalar | Ortam | Zincir Kimliği | rome-evm Program Kimliği | | ----------------- | -------------- | --------------------------------------------- | | Hadrian (testnet) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Rubicon (mainnet) | 7531 | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` | ## Ön derleme Kısıtlamaları | Ön derleme | Kısıt | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Modexp (0x05) | **Devre dışı** — bir çağrı şu hatayla geri alınır `big_mod_exp çağrısı devre dışı` Solana etkinleştirene kadar `big_mod_exp` syscall | | BN254 ecPairing (0x08) | Programın fiyatlandırmasına göre yaklaşık 22K CU artı çift başına 12,8K; dört çiftlik bir kontrol tek bir atomik işleme sığar | | CPI ön derlemesi (0xFF...08) | Hesaplar Solana işleminde önceden bildirilmeli | ## İşlem Doğrulaması | Kural | Etkisi | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | İmza oynanabilirliği (EIP-2) | İmzalanmış bir işlemin `s` değeri eğri düzeninin yarısından büyükse reddedilir | | RLP şekli | RLP listesi son öğesinden sonra artık baytlar taşıyan bir işlem reddedilir | | Gerçekleştirilmemiş opcode | Tüm işlemi iptal eder (`IncompatibleVersionEVM(opcode)`); hiçbir şey işlenmez ve çağıran sözleşme bunu yutamaz | | Gaz ölçümü | Rome'da opcode başına gaz çizelgesi yoktur: gönderilen gaz `CALL`/`CREATE` için uygulanmaz ve 2300 gazlık bir stipend yoktur — stipend tabanlı yeniden giriş korumasına güvenmeyin | ## Oracle Kısıtlamaları | Kısıt | Değer | | -------------------------- | ------------------------------------------------------------------------- | | Varsayılan maksimum eskime | 60 saniye | | Tarihsel tur verileri | Desteklenmiyor — `getRoundData(roundId)` geri alınır | | Switchboard EMA | Desteklenmiyor — `latestEMAData()` SwitchboardV3 üzerinde geri alınır | | Ayrıştırıcı ofsetleri | Deneysel olarak doğrulandı — yeniden dağıtımdan önce yeniden doğrulanmalı | ## Tasarım Önerileri 1. **CPI derinliğini sığ tutun.** İç içeliği en aza indirecek şekilde sözleşmeler tasarlayın. Jupiter'i çağırıp onun Raydium'u, onun da SPL Token'ı çağırması durumunda 3 seviyedesiniz — sınırına tehlikeli derecede yakın. 2. **Atomik modu tercih edin.** İşlemleri \~1,4M CU içinde kalacak şekilde tasarlayın. Yinelemeli mod gecikme ekler (3-4 saniyelik kilitler), oturum başına 160 yineleme sınırı ve cüzdanın adımları kendisi imzaladığı durumlarda Solana hattında her adım için bir cüzdan istemi getirir. Legacy-track CPI yapan bir çağrı, yinelemeli olarak hiç çalışamaz. 3. **Hesapları önceden bildirin.** CPI'nin dokunduğu tüm Solana hesapları işlem oluşturma sırasında bilinmelidir (proxy'nin emülasyonu bunları keşfeder). Bir CPI çağrısı içinde dinamik hesap keşfi mümkün değildir ve toplam 64 adres sınırına sığmalıdır. 4. **Sözleşme başına tek bir ön derleme izini seçin.** Özel bir Solana programı çağırmak (`invoke_signed`) legacy-track'tir ve yalnızca atomiktir; bkz. [Bir Solana programını entegre edin](/tr/gelistirici-kilavuzlari/integrate-solana-program.md). 5. **Kullan `transfer_checked`.** Token-2022 token'larına dokunan herhangi bir şey geliştiriyorsanız, her zaman `transfer_checked` kullanın 6. **CU tüketimini test edin.** İşlem makbuzundan gerçek Solana hesaplama birimlerini ölçün (`computeUnitsConsumed`) — EVM `gasUsed` Solana CU için güvenilir bir vekil değildir. Sıcak yollar için Yul ile optimize edin. ## Sırada Ne Var * [Hesaplama Bütçesi](/tr/temel-kavramlar/compute-budget.md) — işlem başına ayrıntılı CU maliyetleri * [Token Uyumluluğu](/tr/temel-kavramlar/token-interop.md) — ERC-20 ↔ SPL köprüleme modeli * [Ön derleme referansı](/tr/referans/precompiles.md) — her seçici ve onun yönlendirme sınıfı --- # 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/constraints.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.