> 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/id/konsep-inti/execution-model.md).

# 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. Proxy Rome menerima melalui eth_sendRawTransaction
                    ↓
3. Proxy meniru transaksi di luar rantai (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-instruksi tersebut
   → Program Rome EVM menginterpretasikan 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.

**Mesin state:** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**Properti:**

* Eksekusi semuanya atau tidak sama sekali — jika satu langkah gagal, seluruh transaksi dibatalkan
* \~1,4 juta unit komputasi tersedia per transaksi Solana
* Cocok untuk transfer, panggilan kontrak sederhana, swap, sebagian besar operasi DeFi
* Finalitas sub-detik (waktu blok Solana)

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

## Eksekusi Iteratif (VmIt)

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

**Cara kerjanya:**

1. Setiap langkah (sebuah transaksi Solana) mengeksekusi **sebanyak opcode EVM yang muat dalam anggaran komputasinya** — ukuran langkah yang 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 dengan TTL selama **3-4 detik** selama eksekusi multi-langkah; satu sesi dibatasi pada **160 langkah**; setelah itu, langkah berikutnya melepaskan kunci sesi dan mengakhirinya tanpa melakukan komit apa pun

**Mesin state:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**Penguncian akun:**

* Satu **kunci eksklusif** per akun terkelola (akun saldo dan storage) — hanya satu sesi iteratif yang dapat memegang suatu akun pada satu waktu; transaksi atomik yang menulis ke akun yang terkunci ditolak dengan `AccountLocked` sampai kunci berakhir, 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 dipentaskan dan dikomit di akhir

**Saat digunakan:** deployment kontrak besar, call stack yang dalam, operasi apa pun yang melebihi \~1,4 juta CU. Pemeriksaan pairing BN254 sendiri tidak memerlukannya; lihat [Anggaran Komputasi](/id/konsep-inti/compute-budget.md).

## Emulasi

Sebelum mengirim transaksi ke Solana, Proxy menirunya di luar rantai 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 rantai

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

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

## 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 dipentaskan (maks. 80 KB) |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | State VM yang diserialkan antar iterasi       |

## Akun Penampung

Rome mengirim transaksi Solana **v1**, yang dibatasi pada 4 KB (4.096 byte) dan 64 alamat. 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 sebuah `TxHolder` akun melalui `TransmitTx` instruksi
3. Setelah semua potongan dipentaskan, sebuah `DoTxHolder` instruksi merakit dan mengeksekusi transaksi penuh
4. Ukuran maksimum penampung: **80 KB** per TxHolder

Ini sepenuhnya transparan bagi pengembang — SDK Rome menangani pemisahan 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  | Biaya dasar + biaya prioritas                                                                                                                                                                                          |
| Unsigned EIP-1559 | —         | Sebuah `0x02`-typed body tanpa tanda tangan secp256k1, melainkan diotorisasi oleh tanda tangan Ed25519 dari dompet Solana (jalur Solana; lihat [Call EVM from Solana](/id/panduan-pengembang/call-evm-from-solana.md)) |
| Setoran           | Tipe 0x7E | Transaksi deposit, misalnya penyelesaian inbound bridge                                                                                                                                                                |

## State yang Diberi Jurnal

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 bersarang mendorong frame snapshot
* Saat revert: entri jurnal dikembalikan 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](/id/konsep-inti/compute-budget.md) — biaya CU dan strategi optimisasi
* [Batasan](/id/konsep-inti/constraints.md) — batas dan pembatas penting


---

# 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/id/konsep-inti/execution-model.md?ask=<question>&goal=<user_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.