Вызывать EVM из Solana

Позвольте кошельку Solana управлять EVM-контрактами в Rome — без Ethereum-ключа. Кошелёк подписывает, а его транзакция отправляется в Solana.

Обратное направление Вызов Solana из EVM: кошелёк Solana (например, Phantom) напрямую вызывает любой EVM-контракт в Rome, без ключа Ethereum. Так работают Aerarium и Rome DEX позволяют нативным пользователям Solana использовать те же контракты, что и пользователи EVM.

Способ одного вызова в SDK — это submitRomeTxSolanaLane; эта страница объясняет, что он делает.

Синтетические адреса

EVM-идентичность кошелька Solana — это его синтетический адрес — последние 20 байт keccak256 хеша его 32-байтного открытого ключа Solana:

synthetic_evm_address = keccak256(solana_pubkey)[12:]

Это msg.sender при вызове контракта кошельком и стабильная идентичность, под которой находятся его nonce и хранилище. Деривация зафиксирована в протоколе, поэтому кошелёк всегда сопоставляется с одним и тем же адресом.

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

Синтетический адрес — это промежуточный адрес: в состоянии покоя он не хранит токены

Расходуемый баланс нативного пользователя Solana находится в его кошельке Solana (как SPL-токены) и 1:1 отображается на стороне EVM как обёртка ERC20SPL (например, wUSDC). Синтетический адрес ничего не хранит в покое, поэтому стоимость проходит через него — каждый шаг подписан кошельком Solana:

1. Подготовка (один раз). PDA внешней авторизации у совершенно нового синтетического адреса не существует, пока create_pda не выполнится — и нижеприведённые переводы подписываются этим PDA. submitRomeTxSolanaLane автоматически подготавливает его при первом использовании (или вызовите provisionSynthetic для явного шага «Активация»; проверяйте через isSyntheticProvisioned).

2. Этап пополнения (кошелёк → синтетический адрес). Переместите токен из ATA кошелька в ATA синтетического адреса — шаг ActivateAta «ActivateAta», создаваемый buildFundLeg. Теперь wrapper.balanceOf(synthetic) читает этот баланс, поэтому синтетический адрес расходует его как обычный ERC-20 (transfer / transferFrom) — не как нативный msg.value, который он не хранит.

3. Вызов(ы) (DoTxUnsigned). Синтетический адрес выполняет EVM-транзакцию(и) — например, approve затем vault deposit который забирает через transferFrom.

4. Этап вывода (синтетический адрес → кошелёк). После того как withdraw / borrow / claim зачисляет токены на синтетический адрес, buildSweepLeg возвращает их обратно в ATA кошелька пользователя (HelperProgram.transfer_spl), так что на синтетическом адресе итоговый баланс сводится к нулю.

Как формируется вызов

submitRomeTxSolanaLane делает всё это. Механика такая:

1. Сформируйте неподписанную транзакцию EIP-1559 с from = синтетического адреса — без подписи secp256k1.

2. Определите аккаунты — вызовите rome_emulateCallAccounts с полями from, to, data, и value (когда вызов payable). Передача value важна: прокси эмулирует реальный вызов, поэтому любая зависящая от value запись в хранилище — например, новый слот mapping — выделяется, и его аккаунт Solana возвращается. Если его опустить, этот аккаунт будет отсутствовать, и транзакция завершится ошибкой «instruction modified data of a read-only account.»

3. Соберите транзакцию Solana: две ComputeBudget инструкции (EVM Rome требует повышенного лимита CU ≈1,35 млн и большого heap frame ≈250 КБ — значения Solana по умолчанию приводят к сбою) + DoTxUnsigned инструкция (неподписанный RLP + обнаруженные аккаунты) + казначейский кошелёк (при выполнении с него взимается небольшая комиссия; при обнаружении его опускают, поэтому SDK добавляет его).

4. Кошелёк подписывает и отправляет. Кошелёк кошелёк Solana подписывает транзакцию Solana (Ed25519) и отправляет её в Solana RPC — а не в прокси. Среда выполнения Solana проверяет подпись; в сети программа выводит msg.sender из этого подписанта. Полномочия определяются подписью Solana, а не подписью Ethereum. (Прокси используется только для эмуляции/обнаружения на шаге 2.)

PDA пользователя (["EXTERNAL_AUTHORITY", synthetic_address]) владеет его token accounts и подписывает SPL CPI от его имени — так что пользователь Solana может полностью из Phantom вносить, занимать, обменивать и предоставлять ликвидность.

Референсные реализации

• Aerarium — управляет Compound v3 (supply / borrow) из Phantom через DoTxUnsigned.

• Rome DEX — Solana lane торгует и предоставляет ликвидность в том же пуле, что и EVM lane.

Оба решения нативны для Solana, без моста и без второго кошелька — синтетический адрес делает один ключ Phantom полноценным EVM-аккаунтом.

Что дальше

• Вызов Solana из EVM — обратное направление, через CPI

• Интероперабельность токенов — как балансы разделяются между EVM и Solana