> 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

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

## Siklus Transaksi

```
1. Pengguna menandatangani transaksi EVM (MetaMask / ethers.js)
                    ↓
2. Rome Proxy menerima melalui eth_sendRawTransaction
                    ↓
3. Proxy mengemulasikan transaksi off-chain (emulator Mollusk SVM)
   → 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
   → 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 all-or-nothing — jika ada langkah yang gagal, seluruh transaksi di-rollback
* \~1,4 juta unit komputasi tersedia per transaksi Solana
* Cocok untuk transfer, panggilan kontrak sederhana, swap, dan sebagian besar operasi DeFi
* Finalitas di bawah satu detik (waktu blok Solana)

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

## Eksekusi Iteratif (VmIt)

Untuk operasi yang intensif komputasi yang melebihi 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 diserialisasi (format Borsh) ke dalam sebuah `StateHolder` akun
3. Langkah berikutnya mendeserialisasi state dan melanjutkan eksekusi
4. Akun yang terlibat dikunci TTL selama **3-4 detik** selama eksekusi multi-langkah

**Mesin state:** `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)

**Saat digunakan:** Verifikasi pairing BN254, deployment kontrak besar, stack panggilan yang dalam, atau operasi apa pun yang melebihi \~1,4 juta CU.

## Emulasi

Sebelum mengirim transaksi ke Solana, Proxy mengemulasikannya off-chain menggunakan **emulator Mollusk SVM**. 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 mengeksekusi 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` 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:**

| Tipe        | Seed                                         | Tujuan                                    |
| ----------- | -------------------------------------------- | ----------------------------------------- |
| Saldo       | `[chain, "ACCOUN_SEED", H160, bump]`         | Nonce, saldo, kode kontrak                |
| Penyimpanan | `[chain, "STORAGE", H160, slot_index, bump]` | Penyimpanan kontrak (256 slot per akun)   |
| TxHolder    | `[signer, "TX_HOLDER_SEED", index, bump]`    | Data transaksi bertahap (maks. 80 KB)     |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | State VM yang diserialisasi antar iterasi |

## Akun Penampung

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

**Mekanisme pemisahan:**

1. SDK memecah transaksi yang dikodekan 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 — Rome SDK menangani pemisahan dan penyusunan ulang secara otomatis.

## Jenis Transaksi yang Didukung

| Tipe          | EIP       | Deskripsi                                             |
| ------------- | --------- | ----------------------------------------------------- |
| Legacy        | —         | Transaksi Ethereum tradisional                        |
| Daftar Akses  | EIP-2930  | Pola akses state yang dioptimalkan                    |
| Biaya Dinamis | EIP-1559  | Biaya dasar + biaya prioritas                         |
| Deposit       | Tipe 0x7E | Transaksi deposit, misalnya penyelesaian masuk bridge |

## State Berjurnal

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

* Semua perubahan (nonce, saldo, penyimpanan, 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)

## Berikutnya

* [Anggaran Compute](/id/konsep-inti/compute-budget.md) — biaya CU dan strategi optimisasi
* [Batasan](/id/konsep-inti/constraints.md) — batasan dan limit 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/id/konsep-inti/execution-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.