> 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/execution-model.md). # Yürütme Modeli Rome EVM'nin Ethereum işlemlerini Solana üzerinde nasıl işlediği — proxy emülasyonu, atomik (VmAt) ile yinelemeli (VmIt) modlar ve işlemin tam yaşam döngüsü. Rome EVM, Solidity bytecode'unu bir Solana zincir içi programı içinde çalıştırır. Bu sayfa, EVM işlemlerinin nasıl işlendiğini açıklar. ## İşlem Yaşam Döngüsü ``` 1. Kullanıcı EVM işlemini imzalar (MetaMask / ethers.js) ↓ 2. Rome Proxy, işlemi eth_sendRawTransaction üzerinden alır ↓ 3. Proxy, işlemi zincir dışında taklit eder (Mollusk SVM emülatörü) → Gas tahmin eder, atomikliği kontrol eder, gerekli hesapları belirler ↓ 4. Proxy, EVM işlemini Solana talimat(lar)ı olarak sarar → İşlem tek bir Solana işlemine sığıyorsa → Atomik (VmAt) → İşlem CU bütçesini aşıyorsa → İteratif (VmIt) ↓ 5. Solana doğrulayıcısı talimat(lar)ı yürütür → Rome EVM programı, EVM bytecode'unu yorumlar → Diğer Solana programlarına CPI çağrıları (varsa) ↓ 6. Durum değişiklikleri Solana hesaplarına işlenir ↓ 7. Hercules olayı indeksler → EVM bloğu üretir ``` ## Atomik Yürütme (VmAt) Varsayılan moddur. Tüm EVM işlemi tek bir Solana işlemi içinde yürütülür. **Durum makinesi:** `Kilit → Başlat → Yürüt → İşle → GasTransfer → Çıkış` **Özellikler:** * Tam ya da hiç yürütme — herhangi bir adım başarısız olursa, tüm işlem geri alınır * Her Solana işlemi için \~1,4M hesaplama birimi kullanılabilir * Transferler, basit sözleşme çağrıları, takaslar ve çoğu DeFi işlemi için uygundur * Saniyenin altında kesinleşme (Solana blok süresi) **Ne zaman kullanılır:** Emülatör işlemin tek bir Solana işleminin hesaplama bütçesi içine sığdığını belirlediğinde otomatik olarak seçilir. ## İteratif Yürütme (VmIt) Tek bir işlemin bütçesini aşan hesaplama yoğun işlemler için. EVM yürütmesi birden çok Solana işlemine bölünür. **Nasıl çalışır:** 1. Her adım (bir Solana işlemi) yürütür **hesaplama bütçesine sığan kadar çok EVM opcode'u** — sabit bir sayı değil, uyarlanabilir bir adım boyutu 2. Her adımdan sonra, VM durumu seri hale getirilir (Borsh formatı) bir `StateHolder` hesabına 3. Sonraki adım durumu çözer ve yürütmeye devam eder 4. İlgili hesaplar TTL ile kilitlenir **3-4 saniye** çok adımlı yürütme sırasında; bir oturum en fazla **160 adım**; bundan sonra, sonraki adım oturumun kilitlerini serbest bırakır ve hiçbir şey işlemeye almadan oturumu sonlandırır **Durum makinesi:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed` **Hesap kilitleme:** * Her **münhasır kilit** yönetilen hesap başına (bakiye ve depolama hesapları) — aynı anda yalnızca bir iteratif oturum bir hesabı tutabilir; kilitli bir hesaba yazan atomik bir işlem şununla reddedilir `AccountLocked` kilit düşene kadar ve istemci yeniden gönderim yapana kadar, * **TTL:** 3 saniye, her adımda yenilenir (oturum 28'den fazla hesabı etkilediğinde 4 saniye) * **Legacy-track CPI'ler reddedilir** iteratif bir işlem içinde (`CpiProhibitedInIterativeTx`); cached-track etkileri aşamalı olarak hazırlanır ve sonunda işlenir **Ne zaman kullanılır:** büyük sözleşme dağıtımları, derin çağrı yığınları, \~1.4M CU'yu aşan herhangi bir işlem. Tek başına bir BN254 pairing kontrolü buna ihtiyaç duymaz; bkz. [Hesaplama Bütçesi](/tr/temel-kavramlar/compute-budget.md). ## Emülasyon Bir işlemi Solana'ya göndermeden önce, Proxy onu zincir dışında **Mollusk SVM emülatörü** kullanarak taklit eder. Bu: 1. Gas tüketimini tahmin eder 2. Atomik mi yoksa iteratif mod mu gerektiğini belirler 3. İşlemin dokunacağı tüm Solana hesaplarını belirler 4. İşlemin zincir üzerinde başarısız olmayacağını doğrular Emülatör, zincir içi programla aynı EVM mantığını yürütür — `entrypoint!` makrosu, hem program hem de emülatör kod tabanlarında özdeş yönlendirme tabloları sağlar. **Mollusk SVM** emülasyon sırasında keyfi Solana BPF programlarını da çalıştırabilir; bu da `eth_call` ve `eth_estimateGas` SPL Token, Jupiter, Kamino vb. için CPI çağrılarını doğru şekilde ele alabileceği anlamına gelir. ## Hesap Eşleme Her Ethereum adresi bir Solana PDA'sına eşlenir: ``` Ethereum adresi (H160, 20 bayt) ↓ PDA = findProgramAddress( [chain_id, "ACCOUN_SEED", H160, bump], ROME_EVM_PROGRAM_ID ) ↓ Solana hesabı (Pubkey, 32 bayt) ``` **Zincir üzerinde saklanan hesap türleri:** | Tür | Tohumlar | Amaç | | ----------- | -------------------------------------------- | ------------------------------------------------- | | Bakiye | `[chain, "ACCOUN_SEED", H160, bump]` | Nonce, bakiye, sözleşme kodu | | Depolama | `[chain, "STORAGE", H160, slot_index, bump]` | Sözleşme depolaması (hesap başına 256 slot) | | TxHolder | `[signer, "TX_HOLDER_SEED", index, bump]` | Aşamalı işlem verisi (en fazla 80 KB) | | StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | İterasyonlar arasındaki serileştirilmiş VM durumu | ## Holder Hesapları Rome, Solana'ya gönderir **v1 işlemleri**, bunlar 4 KB (4.096 bayt) ve 64 adres ile sınırlıdır. EVM işlemleri — özellikle sözleşme dağıtımları — çok daha büyük olabilir. **Bölme mekanizması:** 1. SDK, RLP ile kodlanmış işlemi parçalara böler 2. Her parça bir `TxHolder` hesabına yazılır `TransmitTx` talimatlarıyla 3. Tüm parçalar aşamalandıktan sonra, bir `DoTxHolder` talimatı tüm işlemi birleştirir ve yürütür 4. Maksimum holder boyutu: **80 KB** TxHolder başına Bu, geliştirici için tamamen şeffaftır — Rome SDK, bölme ve yeniden birleştirmeyi otomatik olarak yönetir. ## Desteklenen İşlem Türleri | Tür | EIP | Açıklama | | --------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Legacy | — | Geleneksel Ethereum işlemleri | | Access List | EIP-2930 | Optimize edilmiş durum erişim desenleri | | Dinamik Ücret | EIP-1559 | Temel ücret + öncelik ücreti | | İmzalanmamış EIP-1559 | — | Bir `0x02`-türünde gövde, secp256k1 imzası olmadan; bunun yerine bir Solana cüzdanının Ed25519 imzasıyla yetkilendirilir (Solana hattı; bkz. [Solana'dan EVM'yi çağırma](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md)) | | Yatırma | 0x7E Türü | Yatırım işlemleri, örn. köprü gelen mutabakatı | ## Günlüklenmiş Durum Rome EVM, yürütme sırasında durum değişikliklerini yönetmek için günlüklenmiş bir durum modeli kullanır: * Tüm değişiklikler (nonce, bakiye, depolama, kod) bir `Günlük` * İç içe CALL/CREATE işlemleri anlık görüntü çerçevelerini yığına ekler * Geri alma durumunda: günlük girdileri anlık görüntüye geri alınır * Başarı durumunda: değişiklikler Solana hesaplarına işlenir * EVM dışı CPI talimatları hemen yürütülür (Solana'nın kendi atomiklik garantileri doğruluğu sağlar) ## Sırada Ne Var * [Hesaplama Bütçesi](/tr/temel-kavramlar/compute-budget.md) — CU maliyetleri ve optimizasyon stratejileri * [Kısıtlamalar](/tr/temel-kavramlar/constraints.md) — önemli sınırlar ve eşikler --- # 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/execution-model.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.