> 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/gelistirici-kilavuzlari/call-evm-from-solana.md). # Solana'dan EVM'yi çağırma Bir Solana cüzdanının Rome üzerindeki EVM sözleşmelerini kullanmasına izin verin — Ethereum anahtarı gerekmez. Cüzdan imzalar ve işlemi Solana'ya gider. tersi [EVM'den Solana'yı çağırma](/tr/gelistirici-kilavuzlari/call-solana-from-evm.md): bir Solana cüzdanı (örneğin Solflare) herhangi bir EVM sözleşmesini Rome üzerinde doğrudan, ile çağırır **Ethereum anahtarı olmadan**. Bu şekilde [Aerarium](/tr/rome-uzerindeki-uygulamalar/apps.md) Solana yerel kullanıcıların EVM kullanıcılarıyla aynı sözleşmeleri paylaşmasını sağlar. Tek çağrılık yöntem, SDK'nın `submitRomeTxV1`, bu çağrı için proxy'nin tek bir Solana v1 işlemi oluşturmasını sağlar; bu sayfa mekanizmayı açıklar. ## Sentetik adresler Bir Solana cüzdanının EVM kimliği onun **sentetik adresidir** — şunun son 20 baytıdır: `keccak256` 32 baytlık Solana açık anahtarının: ``` synthetic_evm_address = keccak256(solana_pubkey)[12:] ``` Bu, `msg.sender` cüzdan bir sözleşme çağırdığında budur; nonce ve depolamasının altında yaşadığı sabit kimliktir. Türetilme protokolde sabitlenmiştir, bu yüzden bir cüzdan her zaman aynı adrese eşlenir. ```javascript import { syntheticAddress } from "@rome-protocol/sdk"; const from = syntheticAddress(solanaPubkey); // 0x… 20 bytes ``` ## Sentetik bir geçiş noktasından ibarettir — durağan halde token tutmaz Bir Solana yerel kullanıcının harcanabilir bakiyesi onların **Solana cüzdanı** (SPL token'ları olarak), EVM tarafında tokenın **ERC20SPL wrapper** (örn. `wUSDC`). Sentetik durağan halde hiçbir şey tutmaz, bu yüzden değer akar *içinden* onun üzerinden — her adım Solana cüzdanı tarafından imzalanır: 1. **Hazırlama (bir kez).** Yepyeni bir sentetiğin external-auth PDA'sı, `create_pda` çalışana kadar mevcut değildir — ve aşağıdaki transferler bu PDA tarafından imzalanır. `submitRomeTxSolanaLane` ilk kullanımda onu otomatik olarak hazırlar (veya çağırın `provisionSynthetic` açık bir "Activate" adımı için; şununla kontrol edin `isSyntheticProvisioned`). İle `submitRomeTxV1`, kontrol edin `isSyntheticProvisioned` ve gönderin `buildCreatePdaCall` bir kez onun üzerinden. 2. **Fonlama adımı (cüzdan → sentetik).** Tokenı cüzdanın ATA'sından sentetiğin ATA'sına taşıyın — `ActivateAta` adımı, tarafından oluşturulan `buildFundLeg`. Artık `wrapper.balanceOf(synthetic)` bu bakiyeyi okur, böylece sentetik bunu sıradan bir ERC-20 olarak harcar (`transfer` / `transferFrom`) — **değil** yerel olarak `msg.value`, çünkü onu tutmaz. 3. **Çağrı(lar) (`DoTxUnsigned`).** Sentetik, EVM işlemlerini yürütür — örn. `approve` sonra bir kasaya `deposit` şunun aracılığıyla çeken `transferFrom`. 4. **Süpürme adımı (sentetik → cüzdan).** Bir withdraw / borrow / claim tokenları sentetiğe düşürdükten sonra, `buildSweepLeg` bunları kullanıcının kendi cüzdan ATA'sına geri iter (`HelperProgram.transfer_spl`), böylece sentetik net olarak sıfıra iner. Sonraki bölüm, daha eski olanın ne yaptığını açıklar `submitRomeTxSolanaLane` istemci tarafında oluşturduğunu. `submitRomeTxV1` proxy'nin bunun yerine bir v1 işlemi oluşturmasını sağlar; kodunuzda hesap keşfi, ComputeBudget veya treasure wallet yoktur; bkz. [external-V1 uç noktaları](#the-external-v1-endpoints) aşağıda ele alınmıştır. ## Çağrının nasıl oluşturulduğu `submitRomeTxSolanaLane` tüm bunları yapar. Mekanik: 1. **İmzalanmamış bir EIP-1559 işlemi oluşturun** ile `from` = sentetik adres — secp256k1 imzası yok. 2. **Hesapları keşfet** — çağırın [`rome_emulateCallAccounts`](/tr/referans/json-rpc.md) çağrının `from`, `buna`, `verisi`, **ve `değeri`** (çağrı payable olduğunda). Geçirmek `değeri` önemlidir: proxy, *gerçek* çağrıyı taklit eder, bu yüzden değere bağlı herhangi bir depolama yazımı — örn. yeni bir mapping slotu — ayrılır ve Solana hesabı döndürülür. Bunu atlayın ve o hesap eksik kalır, işlem de şu hata ile başarısız olur: *"instruction modified data of a read-only account."* 3. **Solana işlemini birleştirin:** iki **ComputeBudget** talimat (Rome'un EVM'si artırılmış bir CU sınırına ≈1,35M ve büyük bir heap frame'ine ≈250 KB ihtiyaç duyar — Solana'nın varsayılanları hata verir) + **`DoTxUnsigned`** talimatı (imzalanmamış RLP + keşfedilen hesaplar) + zincire özgü **hazine cüzdanı** (yürütme ona küçük bir ücret öder; keşif onu atlar, bu yüzden SDK ekler). 4. **Cüzdan imzalar ve gönderir.** Bu **Solana cüzdanı Solana işlemini (Ed25519) imzalar ve onu proxy'ye değil, Solana RPC'ye gönderir.** Solana çalışma zamanı imzayı doğrular; zincir üzerinde program şunu türetir `msg.sender` bu imzalayıcıdan. Yetki, Ethereum imzası değil Solana imzasıdır. (Proxy yalnızca 2. adımda taklit/keşif için kullanılır.) Kullanıcının PDA'sı (`["EXTERNAL_AUTHORITY", synthetic_address]`) token hesaplarına sahiptir ve onların adına SPL CPI'lerini imzalar — böylece bir Solana kullanıcısı tamamen Solana cüzdanından supply, borrow, swap ve LP yapabilir. ## external-V1 uç noktaları `submitRomeTxV1` tek çağrılık yöntemdir: proxy'den oluşturulmuş bir v1 işlem ister, onu kontrol eder, cüzdanın imzalamasını sağlar ve onu Solana RPC'ye gönderir; çağrı uymadığında proxy üzerinden aktarır. Proxy, RPC yöntemleriyle aynı hattı sunar, bu yüzden herhangi bir istemci SDK olmadan da kullanabilir (tam liste [JSON-RPC Desteği](/tr/referans/json-rpc.md)): * `rome_composeUnsignedAtomicV1(rlp, pubkey, signature)` — tek bir Solana v1 işlemi; cüzdan bunu imzalar ve uygulama bunu Solana RPC'ye yayınlar. Çağrı tek bir atomik işleme sığmadığında reddedilir. * `rome_composeUnsignedIterativeV1(rlp, pubkey, signature)` — yürütmenin her adımı (sığıyorsa atomik, aksi halde yinelemeli adımlar); cüzdan her birini imzalar, `rome_submitSignedV1Plan` bunları yayınlar. Uzun bir planın sınırları [Yönlendirilen çağrılar ve uzun çağrılar](#relayed-calls-and-long-calls). * `rome_relayUnsignedV1(rlp, pubkey, signature)` — tek bir cüzdan imzası, proxy'nin ödeyicisi adımları yürütür ve EVM işlem karmasını döndürür; sentetik Rome gazını öder, bu yüzden onu bir kez şununla fonlayın `rome_composeExternalDepositV1`. **Yetkilendirme imzası.** `rlp` çıplak 9 alanlı imzalanmamış EIP-1559 gövdesidir. Cüzdan, Ed25519 anahtarıyla, ya ham 32 baytlık `keccak256(0x02 ‖ rlp)` ya da okunabilir mesajı ``` Rome authorization\n0x<64 lowercase hex chars of that hash> ``` İkisi de kabul edilir; okunabilir biçim, bir cüzdanın `signMessage` isteminde okunaklı biçimde gösterdiği formdur. Program, yürüttüğü gövdeden hash'i yeniden hesaplar ve imzalanmış mesajın tam olarak bu iki biçimden biri olmasını ister; böylece bir gövde üzerindeki bir imza asla başka birini yetkilendiremez ve gövdenin nonce'u yeniden oynatmayı önler. ## Yönlendirilen çağrılar ve uzun çağrılar Bazı çağrılar tek bir Solana işlemine sığmaz. Bu bölüm, o zaman ne olduğunu ve hangi sınırların geçerli olduğunu açıklar. ### Atomik oluşturucu reddettiğinde `rome_composeUnsignedAtomicV1` tek bir atomik işleme sığmayan bir çağrıyı reddeder. `submitRomeTxV1` sonra çağrıyı proxy üzerinden şu **aynı** yetkilendirme imzasıyla aktarır, böylece cüzdandan ikinci kez istenmez. Sonuçta `route: "relay"` ve hiçbir Solana `imzası`. Şunu geçir `relayOnRefusal: false` reddi bunun yerine bir hata olarak almak için, ya da çağırın `relayV1` kasıtlı olarak aktarmak için kendiniz. Aktarılan bir çağrı hakkında bilmeniz gereken üç şey: * **Gazı sentetik öder.** Aktarma yolunda proxy Solana işlemlerini gönderir ve ücretini öder; çağrı, zincirin yerel gaz tokenı ile sentetiğin bakiyesinden ödenir. Bakiye en az `gasLimit × maxFeePerGas`. `fundSyntheticGas(deps, amountWei)` bunu cüzdanın zincirin gaz tokenına ait kendi token hesabından tamamlar (Hadrian ve Rubicon'da USDC); cüzdan tek bir düz v1 işlemi imzalar ve Solana ücreti için biraz SOL'a ihtiyaç duyar. `amountWei` zincirin 18 ondalıklı wei birimindedir ve 10^12'nin katı olmalıdır, aksi halde proxy reddeder. SDK olmadan, `rome_composeExternalDepositV1` aynı işlemi oluşturur. * **Bir revert istisna fırlatmaz.** EVM tarafında revert eden bir aktarılmış çağrı, normal şekilde şu ile sonuçlanır: `receipt.status === "0x0"`çağrıyı tamamlandı saymadan önce. `receipt?.status === "0x1"` Kontrol edin `receipt` olduğu `null` eğer receipt zamanında görünmezse. * **`relayOnRefusal: false` SDK'da verilen bir tercihtir, bir kilit değildir.** Proxy zaten o yük için yetkilendirme imzasını tutar ve onu her iki yoldan da, şu sınıra kadar çalıştırabilir `gasLimit × maxFeePerGas`. ```javascript const res = await submitRomeTxV1(deps, { to, data, value }); if (res.route === "relay" && res.receipt?.status !== "0x1") { // revert eden aktarılan bir çağrı çözümlenir; istisna fırlatmaz } ``` ### Uzun çağrılar Birden fazla işlem gerektiren bir çağrı yinelemeli bir oturum olarak çalışır: program, her Solana işlemine sığan kadar EVM adımı yürütür ve aralarında durumunu kaydeder. Bunu bir Solana cüzdanından yönlendirmek için iki yol: * **Onu aktarın.** `rome_relayUnsignedV1` tek bir cüzdan imzası alır ve proxy'nin ödeyicisi her adımı gönderir. Gazı sentetik öder, yukarıda olduğu gibi. * **Adımları kendiniz imzalayın.** `rome_composeUnsignedIterativeV1` her adımı boş bir imza yuvasıyla döndürür, cüzdan her birini imzalar ve `rome_submitSignedV1Plan` bunları sırayla yayınlar. Her adım, cüzdanın imzalaması için ayrı bir Solana işlemidir; bu yüzden bir seferde bir işlem imzalayan bir cüzdan, yetkilendirme imzasına ek olarak her adım için bir kez istem alır. Cüzdan her adımda Solana ücretini öder. Sınırlar: | Sınır | Değer | Nereden geldiği | | ------------------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------- | | İçindeki işlemler `rome_submitSignedV1Plan` çağrı | 64 | Proxy daha uzun bir planı reddeder | | Yinelemeli oluşturucunun planlayacağı adımlar | 128 | Rust Rome SDK'sinin yinelemeli oluşturucusundaki üst sınır; bu, planı da sınırlar `rome_composeUnsignedIterativeV1` döndürür | | Bir oturumdaki yinelemeler | 160 | Rome EVM programı; bunun ötesinde oturum sürdürmeyi bırakır, hesap kilitlerini serbest bırakır ve sona erer | | Solana işlem boyutu ve hesaplar | 4 KB, 64 adres | Her adım bir Solana v1 işlemidir | Gerçek çağrıların çoğu bu sınırların çok altında sayıda adımda sonuçlanır. Cüzdanın imzaladığı bir plandaki 64 işlem sınırı ilk karşılaşacağınız sınırdır. Bundan daha fazla adım gerektiren bir çağrı üzerinden yayınlanamaz `rome_submitSignedV1Plan`. Uzun bir çağrı legacy-track CPI yapamaz. Legacy precompile'lar üzerindeki değiştiren çağrılar (`0xff…08`, `0xff…09` ve `0x42…16`) yinelemeli oturumda şu ile reddedilir: `CpiProhibitedInIterativeTx`. Solana durumunun okumaları ve cached-track precompile'lar (`0xff…04`, `0xff…05`, `0xff…06`, `0xff…0b`) çalışır. Legacy-track CPI yapan bir çağrının, onu hangi hat gönderirse göndersin tek bir atomik işleme sığması gerekir. Bkz. [Kısıtlar](/tr/temel-kavramlar/constraints.md) ve [Hesaplama Bütçesi](/tr/temel-kavramlar/compute-budget.md). ## Referans uygulamalar * **Aerarium** — Compound v3'ü (supply / borrow) bir Solana cüzdanından şu aracılığıyla çalıştırır: `DoTxUnsigned`. Yukarıda açıklanan daha eski legacy-transaction hattı için referanstır, şu için değil: `submitRomeTxV1`. * **Rome DEX** bu sayfanın bir örneği değildir: Solana tarafı, cüzdanın doğrudan imza attığı yerel bir Solana programıdır ve EVM tarafı aynı havuzu paylaşır. Aerarium'ın köprüye veya ikinci cüzdana ihtiyacı yoktur — sentetik adres, tek bir Solana anahtarını birinci sınıf bir EVM hesabına dönüştürür. v1 kalıbı için şunu izleyin [Çift hatlı bir uygulama oluşturma](/tr/gelistirici-kilavuzlari/dual-lane-app.md). ## Sırada Ne Var * [EVM'den Solana'yı çağırma](/tr/gelistirici-kilavuzlari/call-solana-from-evm.md) — ters yön, CPI aracılığıyla * [Token Uyumluluğu](/tr/temel-kavramlar/token-interop.md) — bakiyelerin EVM ve Solana arasında nasıl paylaşıldığı --- # 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/gelistirici-kilavuzlari/call-evm-from-solana.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.