# 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](/id/konsep-inti/compute-budget.md) — biaya CU dan strategi optimasi
* [Batasan](/id/konsep-inti/constraints.md) — batasan dan ambang penting
* [Siklus Hidup Transaksi](https://github.com/rome-protocol/docs/blob/main/core-concepts/transaction-lifecycle.md) — penjelasan langkah demi langkah yang terperinci


---

# Agent Instructions: 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:

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

The question should be specific, self-contained, and written in natural language.
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.