> 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/vi/cac-khai-niem-cot-loi/execution-model.md).

# Mô hình thực thi

Cách Rome EVM xử lý các giao dịch Ethereum trên Solana — mô phỏng proxy, chế độ atomic (VmAt) so với lặp lại (VmIt), và toàn bộ vòng đời giao dịch.

Rome EVM thực thi bytecode Solidity bên trong một chương trình on-chain của Solana. Trang này giải thích cách các giao dịch EVM được xử lý.

## Vòng đời giao dịch

```
1. Người dùng ký giao dịch EVM (MetaMask / ethers.js)
                    ↓
2. Rome Proxy nhận qua eth_sendRawTransaction
                    ↓
3. Proxy mô phỏng giao dịch ngoài chuỗi (Mollusk SVM emulator)
   → Ước tính gas, kiểm tra tính nguyên tử, xác định các tài khoản cần thiết
                    ↓
4. Proxy đóng gói tx EVM thành (các) lệnh Solana
   → Nếu tx vừa trong một tx Solana → Nguyên tử (VmAt)
   → Nếu tx vượt quá ngân sách CU → Lặp (VmIt)
                    ↓
5. Trình xác thực Solana thực thi (các) lệnh
   → Chương trình Rome EVM diễn giải bytecode EVM
   → Các lệnh gọi CPI tới các chương trình Solana khác (nếu có)
                    ↓
6. Các thay đổi trạng thái được ghi nhận vào các tài khoản Solana
                    ↓
7. Hercules lập chỉ mục sự kiện → tạo khối EVM
```

## Thực thi nguyên tử (VmAt)

Chế độ mặc định. Toàn bộ giao dịch EVM được thực thi trong một giao dịch Solana duy nhất.

**Máy trạng thái:** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**Đặc tính:**

* Thực thi tất cả hoặc không gì cả — nếu bất kỳ bước nào thất bại, toàn bộ giao dịch sẽ hoàn nguyên
* Khoảng 1,4 triệu đơn vị tính toán có sẵn cho mỗi giao dịch Solana
* Phù hợp cho chuyển khoản, gọi hợp đồng đơn giản, hoán đổi, hầu hết các thao tác DeFi
* Tính chung kết dưới một giây (thời gian khối của Solana)

**Khi nào dùng:** Được tự động chọn khi trình mô phỏng xác định giao dịch vừa trong ngân sách tính toán của một giao dịch Solana duy nhất.

## Thực thi lặp (VmIt)

Dành cho các thao tác tốn nhiều tính toán vượt quá ngân sách của một giao dịch. Việc thực thi EVM được chia trên nhiều giao dịch Solana.

**Cách hoạt động:**

1. Mỗi bước (một giao dịch Solana) thực thi **nhiều opcode EVM nhất có thể vừa trong ngân sách tính toán của nó** — kích thước bước thích ứng, không phải số đếm cố định
2. Sau mỗi bước, trạng thái VM được tuần tự hóa (định dạng Borsh) vào một `StateHolder` tài khoản
3. Bước tiếp theo giải tuần tự hóa trạng thái và tiếp tục thực thi
4. Các tài khoản liên quan được khóa TTL trong **3-4 giây** trong quá trình thực thi nhiều bước; một phiên bị giới hạn ở **160 bước**; vượt quá đó, bước tiếp theo sẽ giải phóng các khóa của phiên và kết thúc nó mà không ghi nhận bất kỳ điều gì

**Máy trạng thái:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**Khóa tài khoản:**

* Một **khóa độc quyền** cho mỗi tài khoản được quản lý (tài khoản số dư và lưu trữ) — chỉ một phiên lặp có thể giữ một tài khoản tại một thời điểm; một giao dịch nguyên tử ghi vào tài khoản đang bị khóa sẽ bị từ chối với `AccountLocked` cho đến khi khóa hết hạn, và client gửi lại
* **TTL:** 3 giây, được gia hạn ở mỗi bước (4 giây khi phiên chạm tới hơn 28 tài khoản)
* **Các CPI theo luồng cũ bị từ chối** trong một giao dịch lặp (`CpiProhibitedInIterativeTx`); các hiệu ứng theo luồng cache được dàn dựng và ghi nhận ở cuối

**Khi nào dùng:** triển khai hợp đồng lớn, ngăn xếp gọi sâu, bất kỳ thao tác nào vượt quá \~1,4 triệu CU. Bản thân một phép kiểm tra pairing BN254 thì không cần nó; xem [Ngân sách tính toán](/vi/cac-khai-niem-cot-loi/compute-budget.md).

## Mô phỏng

Trước khi gửi một giao dịch đến Solana, Proxy sẽ mô phỏng nó ngoài chuỗi bằng **trình mô phỏng Mollusk SVM**. Điều này:

1. Ước tính mức tiêu thụ gas
2. Xác định có cần chế độ nguyên tử hay lặp hay không
3. Xác định tất cả các tài khoản Solana mà giao dịch sẽ chạm tới
4. Xác thực giao dịch sẽ không thất bại trên chuỗi

Trình mô phỏng thực thi cùng logic EVM như chương trình on-chain — `entrypoint!` macro đảm bảo các bảng điều phối giống hệt nhau trong cả mã nguồn chương trình lẫn trình mô phỏng.

**Mollusk SVM** cũng có thể thực thi các chương trình BPF tùy ý của Solana trong quá trình mô phỏng, nghĩa là `eth_call` và `eth_estimateGas` xử lý đúng các lời gọi CPI tới SPL Token, Jupiter, Kamino, v.v.

## Ánh xạ tài khoản

Mỗi địa chỉ Ethereum ánh xạ tới một PDA của Solana:

```
Địa chỉ Ethereum (H160, 20 byte)
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
Tài khoản Solana (Pubkey, 32 byte)
```

**Các loại tài khoản được lưu on-chain:**

| Loại        | Seeds                                        | Mục đích                                         |
| ----------- | -------------------------------------------- | ------------------------------------------------ |
| Số dư       | `[chain, "ACCOUN_SEED", H160, bump]`         | Nonce, số dư, mã hợp đồng                        |
| Lưu trữ     | `[chain, "STORAGE", H160, slot_index, bump]` | Lưu trữ hợp đồng (256 ô mỗi tài khoản)           |
| TxHolder    | `[signer, "TX_HOLDER_SEED", index, bump]`    | Dữ liệu giao dịch đã dàn dựng (tối đa 80 KB)     |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | Trạng thái VM được tuần tự hóa giữa các vòng lặp |

## Các tài khoản Holder

Rome gửi các giao dịch Solana **v1**, vốn bị giới hạn ở 4 KB (4.096 byte) và 64 địa chỉ. Các giao dịch EVM — đặc biệt là triển khai hợp đồng — có thể lớn hơn nhiều.

**Cơ chế tách:**

1. SDK chia giao dịch được mã hóa RLP thành các phần
2. Mỗi phần được ghi vào một `TxHolder` tài khoản qua `TransmitTx` các lệnh
3. Khi tất cả các phần đã được dàn dựng, một `DoTxHolder` lệnh sẽ ghép và thực thi toàn bộ giao dịch
4. Kích thước holder tối đa: **80 KB** mỗi TxHolder

Điều này hoàn toàn trong suốt đối với nhà phát triển — Rome SDK tự động xử lý việc chia tách và ghép lại.

## Các loại giao dịch được hỗ trợ

| Loại               | EIP       | Mô tả                                                                                                                                                                                                                                  |
| ------------------ | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Legacy             | —         | Các giao dịch Ethereum truyền thống                                                                                                                                                                                                    |
| Danh sách truy cập | EIP-2930  | Các mẫu truy cập trạng thái được tối ưu hóa                                                                                                                                                                                            |
| Phí động           | EIP-1559  | Phí cơ sở + phí ưu tiên                                                                                                                                                                                                                |
| EIP-1559 không ký  | —         | Một ứng dụng `0x02`thân được gán kiểu 0x02 không có chữ ký secp256k1, mà thay vào đó được ủy quyền bằng chữ ký Ed25519 của ví Solana (luồng Solana; xem [Gọi EVM từ Solana](/vi/huong-dan-cho-nha-phat-trien/call-evm-from-solana.md)) |
| Nạp                | Loại 0x7E | Giao dịch nạp tiền, ví dụ: quyết toán inbound của cầu nối                                                                                                                                                                              |

## Trạng thái nhật ký

Rome EVM sử dụng mô hình trạng thái nhật ký để quản lý các thay đổi trạng thái trong quá trình thực thi:

* Mọi thay đổi (nonce, số dư, lưu trữ, mã) đều được theo dõi trong một `Nhật ký`
* Các thao tác CALL/CREATE lồng nhau sẽ đẩy các khung ảnh chụp nhanh
* Khi hoàn nguyên: các mục nhật ký được quay lui về ảnh chụp nhanh
* Khi thành công: các thay đổi được ghi nhận vào các tài khoản Solana
* Các lệnh CPI không phải EVM được thực thi ngay lập tức (cam kết nguyên tử của Solana đảm bảo tính đúng đắn)

## Tiếp theo là gì

* [Ngân sách tính toán](/vi/cac-khai-niem-cot-loi/compute-budget.md) — chi phí CU và các chiến lược tối ưu hóa
* [Ràng buộc](/vi/cac-khai-niem-cot-loi/constraints.md) — các giới hạn và ranh giới quan trọng


---

# 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/vi/cac-khai-niem-cot-loi/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.