> 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/de/entwicklerleitfaden/call-evm-from-solana.md). # EVM von Solana aus aufrufen Lass eine Solana-Wallet EVM-Verträge auf Rome steuern — kein Ethereum-Schlüssel. Die Wallet signiert, und ihre Transaktion geht an Solana. Das Gegenstück zu [Solana aus EVM aufrufen](/de/entwicklerleitfaden/call-solana-from-evm.md): Eine Solana-Wallet (zum Beispiel Solflare) ruft direkt einen beliebigen EVM-Contract auf Rome auf, mit **keinem Ethereum-Schlüssel**. So [Aerarium](/de/apps-auf-rome/apps.md) können Solana-native Nutzer dieselben Contracts wie EVM-Nutzer gemeinsam verwenden. Der One-Call-Weg ist das SDK- `submitRomeTxV1`, das den Proxy eine einzige Solana-v1-Transaktion für den Aufruf zusammenstellen lässt; diese Seite erklärt die Mechanik. ## Synthetische Adressen Die EVM-Identität einer Solana-Wallet ist ihre **synthetische Adresse** — die letzten 20 Bytes von `keccak256` ihres 32-Byte-Solana-öffentlichen Schlüssels: ``` synthetic_evm_address = keccak256(solana_pubkey)[12:] ``` Das ist die `msg.sender` wenn die Wallet einen Contract aufruft, und die stabile Identität, unter der ihre Nonce und ihr Speicher liegen. Die Ableitung ist im Protokoll verankert, sodass eine Wallet immer derselben Adresse zugeordnet wird. ```javascript import { syntheticAddress } from "@rome-protocol/sdk"; const from = syntheticAddress(solanaPubkey); // 0x… 20 Bytes ``` ## Das Synthetic ist ein Durchleitungsobjekt — es hält im Ruhezustand keine Token Das ausgebbare Guthaben eines Solana-nativen Nutzers liegt in seinem **Solana-Wallet** (als SPL-Token), auf der EVM-Seite 1:1 als **ERC20SPL-Wrapper** (z. B. `wUSDC`). Das Synthetic hält im Ruhezustand nichts, daher fließt Wert *durch* es hindurch — jeder Schritt von der Solana-Wallet signiert: 1. **Einrichtung (einmalig).** Ein brandneues extern-auth-PDA eines Synthetics existiert nicht, bis `create_pda` ausgeführt wird — und die untenstehenden Übertragungen werden von diesem PDA signiert. `submitRomeTxSolanaLane` richtet es bei der ersten Nutzung automatisch ein (oder rufe `provisionSynthetic` für einen expliziten „Aktivieren“-Schritt auf; prüfe mit `isSyntheticProvisioned`). Mit `submitRomeTxV1`, prüfe `isSyntheticProvisioned` und sende `buildCreatePdaCall` einmal hindurch. 2. **Finanzierungsschritt (Wallet → Synthetic).** Verschiebe den Token von der ATA der Wallet in die des Synthetics — der `ActivateAta` Schritt, erstellt von `buildFundLeg`. Jetzt `wrapper.balanceOf(synthetic)` liest diesen Saldo, sodass das Synthetic ihn als gewöhnlichen ERC-20 ausgibt (`transfer` / `transferFrom`) — **nicht** als nativen `msg.value`, den es nicht hält. 3. **Die Aufruf(e) (`DoTxUnsigned`).** Das Synthetic führt die EVM-Transaktion(en) aus — z. B. `approve` dann ein Vault- `deposit` der per `transferFrom`. 4. **Sweep-Schritt (Synthetic → Wallet).** Nachdem ein Withdraw / Borrow / Claim Token im Synthetic abgelegt hat, `buildSweepLeg` schiebt`HelperProgram.transfer_spl`es zurück in die ATA der eigenen Wallet des Nutzers ( Der nächste Abschnitt beschreibt, was das ältere `submitRomeTxSolanaLane` clientseitig baut. `submitRomeTxV1` lässt den Proxy stattdessen eine v1-Transaktion zusammenstellen, ohne Account-Erkennung, ComputeBudget oder Treasure-Wallet in deinem Code; siehe [die externen V1-Endpunkte](#the-external-v1-endpoints) unten. ## Wie der Aufruf aufgebaut wird `submitRomeTxSolanaLane` macht das alles. Die Mechanik: 1. **Eine unsigned EIP-1559-Transaktion erstellen** mit `from` = die synthetische Adresse — keine secp256k1-Signatur. 2. **Accounts ermitteln** — aufrufen [`rome_emulateCallAccounts`](/de/referenz/json-rpc.md) mit den `from`, `zu`, `Daten`, **und `Wert`** (wenn der Aufruf zahlbar ist). Das Übergeben von `Wert` ist wichtig: der Proxy emuliert den *echten* Aufruf, sodass jeder wertabhängige Speicher-Write — z. B. ein frischer Mapping-Slot — angelegt wird und das Solana-Konto zurückgegeben wird. Lässt du es weg, fehlt dieses Konto, und die Transaktion schlägt mit *"instruction modified data of a read-only account."* 3. **Die Solana-Transaktion zusammenstellen:** zwei **ComputeBudget** Instruktionen (Rome's EVM braucht ein erhöhtes CU-Limit ≈1,35 Mio. und einen großen Heap-Frame ≈250 KB — Solanas Standardwerte führen zu einem Fehler) + die **`DoTxUnsigned`** Instruktion (das unsigned RLP + die ermittelten Accounts) + die kettenweite **Treasure-Wallet** (die Ausführung zahlt ihr eine kleine Gebühr; die Ermittlung lässt sie weg, daher hängt das SDK sie an). 4. **Die Wallet signiert und sendet.** Der **Die Solana-Wallet signiert die Solana-Transaktion (Ed25519) und sendet sie an die Solana-RPC — nicht an den Proxy.** Die Solana-Laufzeit verifiziert die Signatur; on-chain leitet das Programm `msg.sender` aus diesem Signer ab. Die Autorität ist die Solana-Signatur, nicht eine Ethereum-Signatur. (Der Proxy wird nur für die Emulation/Ermittlung in Schritt 2 verwendet.) Das PDA des Nutzers (`["EXTERNAL_AUTHORITY", synthetic_address]`) besitzt seine Token-Konten und signiert SPL-CPIs in seinem Namen — sodass ein Solana-Nutzer vollständig aus seiner Solana-Wallet heraus versorgen, leihen, tauschen und LPen kann. ## Die externen V1-Endpunkte `submitRomeTxV1` ist der One-Call-Weg: Er fragt den Proxy nach einer zusammengesetzten v1-Transaktion, prüft sie, lässt die Wallet sie signieren und sendet sie an die Solana-RPC, wobei bei Nichtpassung über den Proxy weitergeleitet wird. Der Proxy stellt dieselbe Bahn als RPC-Methoden zur Verfügung, sodass jeder Client sie ohne das SDK nutzen kann (vollständige Liste in [JSON-RPC-Unterstützung](/de/referenz/json-rpc.md)): * `rome_composeUnsignedAtomicV1(rlp, pubkey, signature)` — eine Solana-v1-Transaktion; die Wallet signiert sie und die App sendet sie an die Solana-RPC. Abgelehnt, wenn der Aufruf nicht in eine einzige atomare Transaktion passt. * `rome_composeUnsignedIterativeV1(rlp, pubkey, signature)` — jede Etappe der Ausführung (atomar, wenn es passt, sonst die iterativen Etappen); die Wallet signiert jede, `rome_submitSignedV1Plan` broadcastet sie. Die Grenzen für einen langen Plan stehen in [Weitergeleitete Aufrufe und lange Aufrufe](#relayed-calls-and-long-calls). * `rome_relayUnsignedV1(rlp, pubkey, signature)` — eine Wallet-Signatur, der Zahler des Proxys treibt die Etappen an und gibt den EVM-Tx-Hash zurück; das Synthetic zahlt Rome-Gas, also lade es einmal auf mit `rome_composeExternalDepositV1`. **Die Autorisierungs-Signatur.** `rlp` ist der nackte 9-Felder-Body einer unsigned EIP-1559-Transaktion. Die Wallet signiert mit ihrem Ed25519-Schlüssel entweder die rohe 32-Byte- `keccak256(0x02 ‖ rlp)` oder die lesbare Nachricht ``` Rome authorization\n0x<64 Kleinbuchstaben-Hexzeichen dieses Hashes> ``` Beides wird akzeptiert; die lesbare Form ist das, was eine Wallet in ihrem `signMessage` Prompt lesbar anzeigt. Das Programm berechnet den Hash aus dem Body neu, den es ausführt, und verlangt, dass die signierte Nachricht genau eine der beiden Formen ist, sodass eine Signatur über einen Body niemals einen anderen autorisieren kann, und die Nonce des Bodys Replays verhindert. ## Weitergeleitete Aufrufe und lange Aufrufe Manche Aufrufe passen nicht in eine einzige Solana-Transaktion. Dieser Abschnitt behandelt, was dann passiert und welche Grenzen gelten. ### Wenn der atomare Composer ablehnt `rome_composeUnsignedAtomicV1` lehnt einen Aufruf ab, der nicht in eine einzige atomare Transaktion passt. `submitRomeTxV1` und leitet den Aufruf dann mit derselben **gleichen** Autorisierungs-Signatur über den Proxy weiter, sodass die Wallet kein zweites Mal gefragt wird. Das Ergebnis hat `route: "relay"` und keine Solana- `Signatur`. Übergebe `relayOnRefusal: false` um die Ablehnung stattdessen als Fehler zu erhalten, oder rufe `relayV1` selbst auf, um absichtlich weiterzuleiten. Drei Dinge, die man über einen weitergeleiteten Aufruf wissen sollte: * **Das Synthetic zahlt das Gas.** Auf dem Relay-Pfad reicht der Proxy die Solana-Transaktionen ein und bezahlt sie, und der Aufruf wird im nativen Gas-Token der Chain aus dem Guthaben des Synthetics bezahlt. Das Guthaben muss mindestens `gasLimit × maxFeePerGas`. `fundSyntheticGas(deps, amountWei)` füllt es aus dem eigenen Token-Konto der Wallet für den Gas-Token der Chain auf (USDC auf Hadrian und Rubicon); die Wallet signiert eine einzige gewöhnliche v1-Transaktion und braucht ein wenig SOL für die Solana-Gebühr. `amountWei` liegt im 18-Dezimal-Wei der Chain und muss ein Vielfaches von 10^12 sein, sonst lehnt der Proxy es ab. Ohne das SDK, `rome_composeExternalDepositV1` stellt dieselbe Transaktion zusammen. * **Ein Revert löst keinen Fehler aus.** Ein weitergeleiteter Aufruf, der auf der EVM-Seite reverts, wird normal aufgelöst, mit `receipt.status === "0x0"`. Prüfe `receipt?.status === "0x1"` bevor du den Aufruf als abgeschlossen behandelst. `receipt` ist `null` wenn das Receipt nicht rechtzeitig erschien. * **`relayOnRefusal: false` ist eine Entscheidung im SDK, keine harte Vorgabe.** Der Proxy hält die Autorisierungs-Signatur für dieses Payload bereits und kann es über beide Wege ausführen, bis zu `gasLimit × maxFeePerGas`. ```javascript const res = await submitRomeTxV1(deps, { to, data, value }); if (res.route === "relay" && res.receipt?.status !== "0x1") { // ein weitergeleiteter Aufruf, der revertiert hat, wird aufgelöst; er wirft keinen Fehler } ``` ### Lange Aufrufe Ein Aufruf, der mehr als eine Transaktion benötigt, läuft als iterative Sitzung ab: Das Programm führt in jeder Solana-Transaktion so viele EVM-Schritte aus, wie hineinpassen, und speichert seinen Zustand dazwischen. Zwei Möglichkeiten, ihn aus einer Solana-Wallet heraus zu steuern: * **Leite ihn weiter.** `rome_relayUnsignedV1` nimmt eine einzige Wallet-Signatur, und der Zahler des Proxys sendet jede Etappe. Das Synthetic zahlt das Gas, wie oben. * **Signiere die Etappen selbst.** `rome_composeUnsignedIterativeV1` gibt jede Etappe mit einem leeren Signaturfeld zurück, die Wallet signiert jede einzelne, und `rome_submitSignedV1Plan` broadcastet sie in Reihenfolge. Jede Etappe ist eine eigene Solana-Transaktion, die die Wallet signieren muss, sodass eine Wallet, die immer nur eine Transaktion auf einmal signiert, pro Etappe einmal zum Prompt auffordert, zusätzlich zur Autorisierungs-Signatur. Die Wallet bezahlt auf jeder Etappe die Solana-Gebühr. Die Grenzen: | Grenze | Wert | Woher sie kommt | | ------------------------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Transaktionen in einem `rome_submitSignedV1Plan` Aufruf | 64 | Der Proxy lehnt einen längeren Plan ab | | Etappen, die der iterative Composer planen wird | 128 | Die Obergrenze im iterativen Composer des Rust-Rome-SDK, die auch den Plan begrenzt `rome_composeUnsignedIterativeV1` liefert | | Iterationen in einer Sitzung | 160 | Das Rome-EVM-Programm; jenseits davon wird die Sitzung nicht mehr fortgesetzt, gibt ihre Account-Sperren frei und endet | | Solana-Transaktionsgröße und Accounts | 4 KB, 64 Adressen | Jede Etappe ist eine Solana-v1-Transaktion | Die meisten echten Aufrufe kommen mit weit weniger Etappen aus als diese Obergrenzen. Die 64-Transaktions-Grenze bei einem von der Wallet signierten Plan ist die, auf die du zuerst stoßen wirst. Ein Aufruf, der mehr Etappen benötigt, kann nicht über `rome_submitSignedV1Plan`. Ein langer Aufruf kann keine CPIs im Legacy-Track machen. Ändernde Aufrufe auf den Legacy-Precompiles (`0xff…08`, `0xff…09` und `0x42…16`) werden in einer iterativen Sitzung mit `CpiProhibitedInIterativeTx`abgelehnt. Lesezugriffe auf Solana-State und die Precompiles des Cached-Tracks (`0xff…04`, `0xff…05`, `0xff…06`, `0xff…0b`) funktionieren. Ein Aufruf, der Legacy-Track-CPIs ausführt, muss in eine einzige atomare Transaktion passen, ganz gleich, welcher Pfad ihn sendet. Siehe [Einschränkungen](/de/kernkonzepte/constraints.md) und [Compute Budget](/de/kernkonzepte/compute-budget.md). ## Referenzimplementierungen * **Aerarium** — steuert Compound v3 (Supply / Borrow) aus einer Solana-Wallet heraus über `DoTxUnsigned`. Es ist die Referenz für den oben beschriebenen älteren Legacy-Transaktionspfad, nicht für `submitRomeTxV1`. * **Rome DEX** ist kein Beispiel für diese Seite: Seine Solana-Seite ist ein nativer Solana-Programm, für das die Wallet direkt signiert, und seine EVM-Seite teilt sich denselben Pool. Aerarium braucht keine Bridge oder zweite Wallet — die synthetische Adresse macht aus einem Solana-Schlüssel ein vollwertiges EVM-Konto. Für das v1-Muster folge [Eine Dual-Lane-App bauen](/de/entwicklerleitfaden/dual-lane-app.md). ## Wie es weitergeht * [Solana aus EVM aufrufen](/de/entwicklerleitfaden/call-solana-from-evm.md) — die andere Richtung, per CPI * [Token-Interop](/de/kernkonzepte/token-interop.md) — wie Salden zwischen EVM und Solana geteilt werden --- # 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/de/entwicklerleitfaden/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.