Model Eksekusi

Rome EVM menjalankan 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 mengemulasikan transaksi secara off-chain (emulator Mollusk SVM)
   → Memperkirakan 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 tersebut
   → Program Rome EVM menafsirkan bytecode EVM
   → Panggilan CPI ke program Solana lainnya (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 semua-atau-tidak-sama-sekali — jika salah satu langkah gagal, seluruh transaksi dibatalkan

• ~1,4 juta compute units tersedia per transaksi Solana

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

• Finalitas sub-detik (waktu blok Solana)

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

Eksekusi Iteratif (VmIt)

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

Cara kerjanya:

1. Setiap langkah mengeksekusi kira-kira 500 opcode EVM

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

3. Langkah berikutnya mendeserialisasi state dan melanjutkan eksekusi

4. Akun yang terlibat dikunci TTL selama 3-4 detik selama eksekusi multi-langkah

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

Penguncian akun:

• RoLock (baca-saja bersama) — Beberapa transaksi iteratif dapat menahannya secara bersamaan

• RwLock (tulis eksklusif) — Hanya satu transaksi yang dapat memodifikasi akun pada satu waktu

• TTL: 3 detik (standar), 4 detik (saat menggunakan Address Lookup Tables)

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

Emulasi

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

1. Memperkirakan 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 di on-chain

Emulator mengeksekusi logika EVM yang sama seperti program on-chain — entrypoint! macro memastikan tabel dispatch yang identik di kedua 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 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 dipentaskan (maks. 80 KB)
StateHolder	[signer, "STATE_HOLDER_SEED", index, bump]	State VM yang diserialkan di antara iterasi

Akun Holder

Transaksi Solana dibatasi hingga 1.232 byte. Transaksi EVM — terutama deployment kontrak — bisa jauh lebih besar.

Mekanisme pemisahan:

1. SDK memecah transaksi yang dienkode RLP menjadi beberapa potongan

2. Setiap potongan ditulis ke TxHolder akun melalui TransmitTx instruksi

3. Setelah semua potongan dipentaskan, sebuah DoTxHolder instruksi merakit dan mengeksekusi transaksi penuh

4. Ukuran maksimum holder: 80 KB per TxHolder

Ini sepenuhnya transparan bagi developer — Rome SDK menangani pemisahan dan perakitan 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	Biaya dasar + biaya prioritas
Deposit	Tipe 0x7E	Transaksi deposit L2 (diinisiasi sequencer)

Journaled State

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

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

• Operasi CALL/CREATE bertingkat mendorong frame snapshot

• Saat revert: entri jurnal dipulihkan ke snapshot

• Saat berhasil: perubahan dikomit ke akun Solana

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

Berikutnya

• Anggaran Komputasi — biaya CU dan strategi optimasi

• Batasan — batasan dan ambang penting

• Siklus Hidup Transaksi — penjelasan langkah demi langkah yang terperinci