> 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/bat-dau/architecture.md).
# Kiến trúc
Các thành phần của Rome khớp với nhau như thế nào — thực thi EVM bên trong một chương trình Solana.
Rome nhúng một bộ thông dịch bytecode EVM bên trong một chương trình on-chain của Solana. Người dùng giao tiếp với Rome Proxy qua chuẩn Ethereum JSON-RPC, và proxy gửi trực tiếp các giao dịch của họ tới chương trình Rome EVM trên Solana. Không có lớp thực thi riêng nào cần đồng bộ — trạng thái EVM *là* Trạng thái Solana.
## Tổng quan hệ thống
## Các thành phần
### Chương trình Rome EVM (trên chuỗi)
Trái tim của Rome — một chương trình Solana BPF chứa một bộ thông dịch bytecode EVM đầy đủ (một nhánh của SputnikVM). Nó:
* Nhận các giao dịch EVM đã tuần tự hóa dưới dạng các chỉ thị Solana
* Thực thi bytecode Solidity bên trong môi trường runtime của Solana
* Ánh xạ mỗi địa chỉ Ethereum (H160) tới một PDA Solana
* Cung cấp các precompile để gọi vào Solana (CPI, System, Helper, Withdraw) bên cạnh các precompile Ethereum tiêu chuẩn
* Lưu trạng thái EVM (số dư, nonce, mã, bộ nhớ lưu trữ) dưới dạng dữ liệu tài khoản Solana
### Rome Proxy (máy chủ JSON-RPC)
Một máy chủ Ethereum JSON-RPC tiêu chuẩn trên cổng 9090 — điểm vào cho các chuỗi công khai. Nó chuyển các lời gọi API Ethereum thành hoạt động Solana:
* `eth_sendRawTransaction` → tuần tự hóa tx EVM → gửi một chỉ thị Solana
* `eth_call` → mô phỏng việc thực thi ngoài chuỗi qua trình giả lập Mollusk SVM
* `eth_estimateGas` → mô phỏng để ước tính gas
* `eth_getBalance`, `eth_getCode`, `eth_getBlockByNumber`, biên lai, log → được phục vụ từ trạng thái đã lập chỉ mục
Nó cũng cung cấp các tiện ích mở rộng của Rome: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo`, `rome_getResources`, và hơn thế nữa.
### Hercules (bộ lập chỉ mục)
Theo dõi chương trình Rome EVM trên Solana và tái tạo các block tương thích với Ethereum — giao dịch, biên lai, log và các thay đổi trạng thái — được hỗ trợ bởi PostgreSQL. Trên các chuỗi công khai, nó chạy ở chế độ căn theo slot, nên số block ánh xạ tới một slot Solana và cùng một slot sẽ cho ra cùng một block trên bất kỳ bộ lập chỉ mục nào. Proxy phục vụ các block này cho ví và trình khám phá.
### Precompile
Rome triển khai các precompile Ethereum tiêu chuẩn (ecrecover, SHA-256, RIPEMD-160, identity, modexp, các phép toán trên đường cong BN254, blake2f) với ngữ nghĩa tương đương mainnet, cộng thêm các precompile không phải EVM chạm vào Solana: **CpiProgram** (`0xFF…08`, CPI tùy ý), **System** (`0xFF…07`, suy ra PDA và các tiện ích base58), **HelperProgram** (`0xFF…09`, tạo ATA/PDA, chuyển SPL, gas↔lamports), và **Rút** (`0x42…16`). Xem [Địa chỉ Hợp đồng](/vi/tai-lieu-tham-khao/contract-addresses.md) tài liệu tham khảo để xem bảng đầy đủ.
## Các chế độ thực thi
Rome thực thi một giao dịch EVM theo một trong hai cách:
### Nguyên tử (VmAt)
Một giao dịch Solana duy nhất. Toàn bộ giao dịch EVM được thực thi trong ngân sách tính toán của một giao dịch Solana (\~1,4 triệu đơn vị tính toán). Dùng cho hầu hết các thao tác — chuyển tiền, gọi hợp đồng thông thường, hoán đổi.
### Lặp (VmIt)
Dành cho các tác vụ vượt quá ngân sách của một giao dịch duy nhất. Việc thực thi được chia trên nhiều giao dịch Solana:
1. Mỗi bước (một giao dịch Solana) chạy số lượng opcode EVM tối đa vừa với ngân sách tính toán của nó — kích thước bước là thích ứng, không cố định
2. Trạng thái VM được tuần tự hóa Borsh vào một `StateHolder` tài khoản giữa các bước
3. Các tài khoản được khóa TTL trong vài giây trong quá trình thực thi
4. Dùng cho các thao tác nặng như ghép cặp BN254
## Ánh xạ tài khoản
Mỗi địa chỉ Ethereum được ánh xạ một cách xác định tới một PDA Solana được suy ra từ chain ID và địa chỉ dưới chương trình Rome EVM. PDA đó sở hữu số dư của tài khoản (dưới dạng tài khoản token SPL), mã hợp đồng, các slot lưu trữ và nonce — tất cả đều là dữ liệu tài khoản Solana.
## Tài khoản holder
Các giao dịch Solana (v1) bị giới hạn ở 4 KB, nhưng các giao dịch EVM (đặc biệt là triển khai hợp đồng) có thể lớn hơn nhiều. Rome chia các giao dịch lớn vào **các tài khoản chứa tạm**: giao dịch được chia thành các khối nhỏ ghi tuần tự vào một holder (tối đa 80 KB), rồi được ghép lại và thực thi on-chain. Bộ SDK Rome xử lý việc này một cách trong suốt.
## Gas và định giá
Mỗi chuỗi có token gas riêng — bất kỳ token SPL nào. Định giá gas đọc một pool Meteora DAMM (v1 hoặc v2, có thể cấu hình) để chuyển đổi giữa token gas và SOL cho phí giao dịch Solana nền tảng.
## Tiếp theo là gì
* [Mạng](/vi/mang/networks.md) — kết nối với Hadrian
* [Bắt đầu nhanh](/vi/bat-dau/quickstart.md) — triển khai hợp đồng đầu tiên của bạn
* [Mô hình thực thi](/vi/cac-khai-niem-cot-loi/execution-model.md) — thực thi nguyên tử và thực thi lặp lại chuyên sâu
---
# 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/bat-dau/architecture.md?ask=&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.
