Model Eksekusi

Cara Rome EVM memproses transaksi Ethereum di Solana — emulasi proxy, mode atomik (VmAt) vs. iteratif (VmIt), dan siklus hidup transaksi lengkap.

Rome EVM mengeksekusi bytecode Solidity di dalam program on-chain Solana. Halaman ini menjelaskan bagaimana transaksi EVM diproses.

Siklus Hidup Transaksi

1. Pengguna menandatangani transaksi EVM (MetaMask / ethers.js)
                    ↓
2. Rome Proxy menerima melalui eth_sendRawTransaction
                    ↓
3. Proxy meniru transaksi secara off-chain (emulator SVM Mollusk)
   → Mengestimasi gas, memeriksa atomisitas, mengidentifikasi akun yang diperlukan
                    ↓
4. Proxy membungkus tx EVM sebagai instruksi Solana
   → Jika tx muat dalam satu tx Solana → Atomik (VmAt)
   → Jika tx melebihi anggaran CU → Iteratif (VmIt)
                    ↓
5. Validator Solana mengeksekusi instruksi-instruksi tersebut
   → Program Rome EVM menafsirkan bytecode EVM
   → Panggilan CPI ke program Solana lain (jika ada)
                    ↓
6. Perubahan state dikomit ke akun Solana
                    ↓
7. Hercules mengindeks event → menghasilkan blok EVM

Eksekusi Atomik (VmAt)

Mode default. Seluruh transaksi EVM dieksekusi dalam satu transaksi Solana.

State machine: Lock → Init → Execute → Commit → GasTransfer → Exit

Properti:

• Eksekusi all-or-nothing — jika satu langkah gagal, seluruh transaksi di-revert

• ~1,4 juta unit komputasi tersedia per transaksi Solana

• Cocok untuk transfer, panggilan kontrak sederhana, swap, sebagian besar operasi DeFi

• Finalitas di bawah satu detik (waktu blok Solana)

Kapan digunakan: Dipilih secara otomatis ketika emulator menentukan bahwa transaksi muat dalam anggaran komputasi satu transaksi Solana.

Eksekusi Iteratif (VmIt)

Untuk operasi yang intensif komputasi dan melampaui anggaran satu transaksi. Eksekusi EVM dibagi ke beberapa transaksi Solana.

Cara kerjanya:

1. Setiap langkah (sebuah transaksi Solana) mengeksekusi sebanyak opcode EVM yang muat dalam anggaran komputasinya — ukuran langkah adaptif, bukan jumlah tetap

2. Setelah setiap langkah, state VM diserialkan (format Borsh) ke dalam sebuah StateHolder akun

3. Langkah berikutnya mendeserialkan state dan melanjutkan eksekusi

4. Akun yang terlibat dikunci TTL selama 3-4 detik selama eksekusi multi-langkah; sebuah sesi dibatasi pada 160 langkah; setelah itu, langkah berikutnya melepaskan kunci sesi dan mengakhirinya tanpa meng-commit apa pun

State machine: FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed

Penguncian akun:

• Satu kunci eksklusif per akun yang dikelola (akun saldo dan storage) — hanya satu sesi iteratif yang dapat memegang sebuah akun pada satu waktu; transaksi atomik yang menulis akun yang terkunci ditolak dengan AccountLocked sampai kuncinya kedaluwarsa, dan klien mengirim ulang

• TTL: 3 detik, diperbarui setiap langkah (4 detik ketika sesi menyentuh lebih dari 28 akun)

• CPI jalur legacy ditolak di dalam transaksi iteratif (CpiProhibitedInIterativeTx); efek jalur cached disiapkan dan di-commit di akhir

Kapan digunakan: Verifikasi pairing BN254, deployment kontrak besar, call stack yang dalam, operasi apa pun yang melebihi ~1,4 juta CU.

Emulasi

Sebelum mengirim transaksi ke Solana, Proxy menirunya secara off-chain menggunakan emulator SVM Mollusk. Ini:

1. Mengestimasi konsumsi gas

2. Menentukan apakah mode atomik atau iteratif diperlukan

3. Mengidentifikasi semua akun Solana yang akan disentuh transaksi

4. Memvalidasi bahwa transaksi tidak akan gagal on-chain

Emulator menjalankan logika EVM yang sama seperti program on-chain — entrypoint! makro memastikan tabel dispatch yang identik di basis kode program dan emulator.

Mollusk SVM juga dapat mengeksekusi program Solana BPF arbitrer selama emulasi, yang berarti eth_call dan eth_estimateGas menangani dengan benar panggilan CPI ke SPL Token, Jupiter, Kamino, dll.

Pemetaan Akun

Setiap alamat Ethereum dipetakan ke sebuah PDA Solana:

Alamat Ethereum (H160, 20 byte)
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
Akun Solana (Pubkey, 32 byte)

Jenis akun yang disimpan on-chain:

Jenis	Seed	Tujuan
Saldo	[chain, "ACCOUN_SEED", H160, bump]	Nonce, saldo, kode kontrak
Storage	[chain, "STORAGE", H160, slot_index, bump]	Storage kontrak (256 slot per akun)
TxHolder	[signer, "TX_HOLDER_SEED", index, bump]	Data transaksi yang disiapkan (maks. 80 KB)
StateHolder	[signer, "STATE_HOLDER_SEED", index, bump]	State VM yang diserialkan di antara iterasi

Akun Holder

Rome mengirim transaksi Solana v1yang dibatasi hingga 4 KB (4.096 byte) dan 64 alamat. Transaksi EVM — terutama deployment kontrak — bisa jauh lebih besar.

Mekanisme pemecahan:

1. SDK memecah transaksi yang dienkode RLP menjadi potongan-potongan

2. Setiap potongan ditulis ke sebuah TxHolder akun melalui TransmitTx instruksi

3. Setelah semua potongan disiapkan, sebuah DoTxHolder instruksi merakit dan mengeksekusi transaksi lengkap

4. Ukuran maksimum holder: 80 KB per TxHolder

Ini sepenuhnya transparan bagi pengembang — SDK Rome menangani pemecahan dan penyusunan ulang secara otomatis.

Jenis Transaksi yang Didukung

Jenis	EIP	Deskripsi
Legacy	—	Transaksi Ethereum tradisional
Access List	EIP-2930	Pola akses state yang dioptimalkan
Dynamic Fee	EIP-1559	Base fee + priority fee
Unsigned EIP-1559	—	Sebuah 0x02-bertipe tanpa tanda tangan secp256k1, yang diotorisasi oleh tanda tangan Ed25519 dari dompet Solana sebagai gantinya (jalur Solana; lihat Panggil EVM dari Solana)
Deposit	Tipe 0x7E	Transaksi deposit, misalnya penyelesaian masuk dari bridge

State Berjurnal

Rome EVM menggunakan model state berjurnal untuk mengelola perubahan state selama eksekusi:

• Semua perubahan (nonce, saldo, storage, kode) dilacak dalam sebuah Jurnal

• Operasi CALL/CREATE bertingkat mendorong frame snapshot

• Saat revert: entri jurnal digulung balik ke snapshot

• Saat berhasil: perubahan dikomit ke akun Solana

• Instruksi CPI non-EVM dieksekusi segera (jaminan atomisitas Solana sendiri memastikan kebenaran)

Apa Selanjutnya

• Anggaran Komputasi — biaya CU dan strategi optimalisasi

• Batasan — batas dan kendala penting