EVM von Solana aus aufrufen

Lassen Sie eine Solana-Wallet EVM-Verträge auf Rome steuern — ohne Ethereum-Schlüssel. Die Wallet signiert, und ihre Transaktion geht an Solana.

Das Gegenstück zu Solana von EVM aus aufrufen: Eine Solana-Wallet (z. B. Phantom) ruft direkt einen beliebigen EVM-Contract auf Rome auf, mit ohne Ethereum-Schlüssel. So Aerarium und Rome DEX ermöglichen es Solana-nativen Nutzern, dieselben Contracts wie EVM-Nutzer zu nutzen.

Der Einmalaufruf-Weg ist die des SDKs submitRomeTxSolanaLane; diese Seite erklärt, was es tut.

Synthetische Adressen

Die EVM-Identität einer Solana-Wallet ist ihre synthetische Adresse — die letzten 20 Bytes des keccak256 ihres 32-Byte-Solana-Public-Keys:

synthetic_evm_address = keccak256(solana_pubkey)[12:]

Dies ist der msg.sender wenn die Wallet einen Contract aufruft, und die stabile Identität, unter der ihr Nonce und ihr Speicher liegen. Die Ableitung ist im Protokoll fest verankert, sodass eine Wallet immer derselben Adresse zugeordnet wird.

import { syntheticAddress } from "@rome-protocol/sdk";
const from = syntheticAddress(solanaPubkey); // 0x… 20 Bytes

Das Synthetic ist nur ein Durchleiter — es hält im Ruhezustand keine Tokens

Das ausgebbare Guthaben eines Solana-nativen Nutzers liegt in seiner Solana-Wallet (als SPL-Token), auf der EVM-Seite 1:1 als ERC20SPL-Wrapper (z. B. wUSDC). Das Synthetic hält im Ruhezustand nichts, sodass der Wert fließt durch es — jeder Schritt von der Solana-Wallet signiert:

1. Bereitstellung (einmalig). Das externe Auth-PDA eines brandneuen Synthetic existiert nicht, bis create_pda ausgeführt wird — und die untenstehenden Transfers von diesem PDA signiert werden. submitRomeTxSolanaLane stellt es bei der ersten Verwendung automatisch bereit (oder rufe provisionSynthetic für einen expliziten „Aktivieren“-Schritt auf; prüfe mit isSyntheticProvisioned).

2. Finanzierungspfad (Wallet → Synthetic). Verschiebe den Token aus dem ATA der Wallet in den des Synthetic — der ActivateAta Schritt, erstellt von buildFundLeg. Jetzt wrapper.balanceOf(synthetic) liest dieses Guthaben, sodass der Synthetic es als gewöhnlichen ERC-20 ausgibt (transfer / transferFrom) — nicht als nativer msg.value, den er nicht hält.

3. Der/die Aufruf(e) (DoTxUnsigned). Das Synthetic führt die EVM-Transaktion(en) aus — z. B. approve dann ein Vault deposit das zieht über transferFrom.

4. Sweep-Pfad (Synthetic → Wallet). Nachdem ein withdraw / borrow / claim Tokens im Synthetic landen lässt, buildSweepLeg schiebt sie zurück in das ATA der Wallet des Nutzers (HelperProgram.transfer_spl), sodass das Synthetic netto auf null kommt.

Wie der Aufruf gebaut wird

submitRomeTxSolanaLane erledigt all das. Die Mechanik:

1. Erstelle eine unsignierte EIP-1559-Transaktion mit von = der synthetischen Adresse — keine secp256k1-Signatur.

2. Konten ermitteln — rufe rome_emulateCallAccounts mit dem von, to, Daten, und Wert (wenn der Aufruf payable ist). Das Übergeben von Wert ist wichtig: Der Proxy emuliert den echten Aufruf, sodass jeder wertabhängige Speicher-Schreibvorgang — z. B. ein neuer Mapping-Slot — angelegt wird und sein Solana-Konto zurückgegeben wird. Lässt du es weg, fehlt dieses Konto, und die Transaktion schlägt fehl mit "instruction modified data of a read-only account."

3. Stelle die Solana-Transaktion zusammen: zwei ComputeBudget Anweisungen (Rome's EVM benötigt ein erhöhtes CU-Limit von ca. 1,35 Mio. und einen großen Heap-Frame von ca. 250 KB — Solanas Standardwerte führen zu einem Fehler) + die DoTxUnsigned Anweisung (das unsignierte RLP + die ermittelten Konten) + der kettenbezogene Treasury-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 ab. Die Solana-Wallet signiert die Solana-Transaktion (Ed25519) und sendet sie an das Solana-RPC — nicht an den Proxy. Die Solana-Runtime überprüft die Signatur; on-chain leitet das Programm msg.sender daraus den entsprechenden Wert 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 ihrem Namen — sodass ein Solana-Nutzer vollständig aus Phantom heraus bereitstellen, leihen, tauschen und Liquidität bereitstellen kann.

Referenzimplementierungen

• Aerarium — steuert Compound v3 (supply / borrow) aus Phantom heraus über DoTxUnsigned.

• Rome DEX — die Solana-Lane handelt und stellt Liquidität im selben Pool wie die EVM-Lane bereit.

Beide sind Solana-nativ, ohne Bridge oder zweite Wallet — die synthetische Adresse macht einen Phantom-Schlüssel zu einem vollwertigen EVM-Konto.

Wie geht es weiter

• Solana von EVM aus aufrufen — die andere Richtung, via CPI

• Token-Interop — wie Guthaben zwischen EVM und Solana geteilt werden