> 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/key-concepts.md).

# Khái niệm chính

Thuật ngữ thiết yếu của Solana và Rome EVM dành cho nhà phát triển — program, account, PDA, CPI, token SPL, và thực thi atomic so với lặp lại.

Các thuật ngữ và khái niệm thiết yếu để xây dựng trên Rome Protocol.

## Khái niệm về Solana

**Chương trình** — Tương đương của hợp đồng thông minh trên Solana. Các chương trình là các tệp thực thi không trạng thái được triển khai on-chain. Bản thân Rome EVM cũng là một chương trình Solana.

**Tài khoản** — Toàn bộ trạng thái trên Solana đều nằm trong các tài khoản. Mỗi tài khoản có một chủ sở hữu (chương trình), một số dư (lamport) và dữ liệu. Không giống Ethereum, mã và trạng thái được lưu trong các tài khoản riêng biệt.

**Địa chỉ dẫn xuất từ chương trình (PDA)** — Một địa chỉ xác định được dẫn xuất từ seed và một program ID. PDA cho phép các chương trình "sở hữu" tài khoản mà không cần khóa riêng. Rome dùng PDA để ánh xạ địa chỉ Ethereum sang tài khoản Solana.

**Lời gọi liên chương trình (CPI)** — Một chương trình Solana gọi chương trình khác trong cùng một giao dịch. Đây là cách các hợp đồng Rome EVM tương tác với Jupiter, Kamino, SPL Token và các chương trình Solana khác.

**SPL Token** — Chương trình token tiêu chuẩn của Solana. Tương đương ERC-20 trên Ethereum. Tất cả token có thể thay thế trên Solana (USDC, SOL, v.v.) đều là token SPL.

**Token-2022** — Chương trình token SPL thế hệ tiếp theo với các tiện ích mở rộng như Transfer Hooks, Confidential Transfers và Permanent Delegates.

**Hook chuyển khoản** — Một tiện ích mở rộng của Token-2022 kích hoạt một chương trình trong mọi `transfer_checked` lần gọi.

**ATA (Tài khoản token liên kết)** — Một tài khoản token xác định được cho một cặp ví + mint nhất định. Mỗi người dùng có một ATA cho mỗi token họ nắm giữ.

**Lamport** — Đơn vị nhỏ nhất của SOL. 1 SOL = 1.000.000.000 lamport (10^9).

**Đơn vị tính toán (CU)** — Tương đương gas của Ethereum trên Solana. Mỗi giao dịch có một ngân sách tính toán (mặc định khoảng 200K CU, tối đa khoảng 1,4M CU). Các thao tác tiêu thụ CU.

## Khái niệm về Rome

**Chương trình Rome EVM** — Chương trình Solana chứa trình thông dịch bytecode EVM. Được triển khai tại một program ID cụ thể cho từng môi trường.

**Mã Chain** — Mỗi ứng dụng trên Rome có chain ID EVM riêng. Điều này tạo ra các môi trường EVM biệt lập nhưng dùng chung trạng thái Solana nền tảng.

**Thực thi nguyên tử (VmAt)** — Một giao dịch EVM được thực thi hoàn toàn trong một giao dịch Solana duy nhất. Được dùng cho hầu hết các thao tác.

**Thực thi lặp (VmIt)** — Một giao dịch EVM được chia thành nhiều giao dịch Solana, mỗi bước đóng gói số lượng opcode tối đa vừa với ngân sách tính toán của một giao dịch Solana (thích ứng, không phải số cố định). Được dùng cho các thao tác tốn nhiều tính toán như ghép cặp BN254.

**Tài khoản giữ** — Một bộ đệm on-chain lưu trữ các giao dịch EVM lớn (tối đa 80 KB) vượt quá giới hạn kích thước giao dịch 4 KB của Solana (v1). Được SDK quản lý một cách trong suốt.

**StateHolder** — Một tài khoản on-chain lưu trữ trạng thái VM đã được tuần tự hóa giữa các bước thực thi lặp.

**Proxy Rome** — Máy chủ JSON-RPC (cổng 9090) dịch các lệnh gọi API Ethereum thành giao dịch Solana. MetaMask và Hardhat của bạn kết nối tại đây.

**Hercules** — Bộ lập chỉ mục khối giám sát các sự kiện Rome EVM trên Solana và tạo dữ liệu khối tương thích Ethereum.

**Bên thanh toán** — Một cặp khóa Solana ký và thanh toán cho các giao dịch Solana thay mặt người dùng EVM. Được Proxy quản lý thông qua các pool payer.

## Khái niệm về token

**SPL\_ERC20 / SPL\_ERC20\_cached** — Các hợp đồng bao bọc ERC-20 đại diện cho một token SPL trong Rome EVM. Với một ví, hợp đồng bao bọc đọc số dư trực tiếp từ tài khoản token SPL nền tảng. Các token do hợp đồng nắm giữ nằm trong tài khoản token ký quỹ riêng của hợp đồng bao bọc và được theo dõi trong lưu trữ của hợp đồng bao bọc (xem [Tích hợp một chương trình Solana](/vi/huong-dan-cho-nha-phat-trien/integrate-solana-program.md)). Hiện nay factory triển khai biến thể được lưu đệm.

**ERC20SPLFactory** — Một hợp đồng factory triển khai các wrapper cho bất kỳ token SPL nào.

**Sổ đăng ký** — Các wrapper chuẩn, gas token và cấu hình cầu nối được tuyển chọn ngoài chuỗi trong [rome-protocol/registry](https://github.com/rome-protocol/rome-registry); không có hợp đồng registry token on-chain. Điều này giúp mỗi tài sản được ánh xạ tới một SPL mint chuẩn duy nhất.

## Precompile

**Các precompile tiêu chuẩn của Ethereum** — ecrecover (0x01), SHA-256 (0x02), RIPEMD-160 (0x03), identity (0x04), modexp (0x05), BN254 ecAdd/ecMul/ecPairing (0x06-0x08), Blake2f (0x09).

**Precompile hệ thống** (`0xFF...07`) — dẫn xuất PDA và chuyển đổi base58 từ Solidity.

**Precompile CpiProgram** (`0xFF...08`) — gọi liên chương trình (`invoke` / `invoke_signed`) cùng các lối tắt đọc trạng thái chéo.

**Precompile HelperProgram** (`0xFF...09`) — tạo ATA/PDA, chuyển SPL và quy đổi gas↔lamport; bề mặt chính cho các thao tác SPL được ký bởi user-PDA.

**Precompile rút tiền** (`0x42...16`) — Rút SOL hoặc token SPL từ EVM trở lại Solana.

Một họ track được lưu đệm (`0xff…04/05/06/0b`) sao chép các mục này để đọc hiệu quả về CU; một hợp đồng sử dụng nhất quán một track.

## Các kiểu giao dịch

**RheaTx** — Một giao dịch EVM duy nhất trên một rollup. Loại phổ biến nhất.

**RemusTx** — Nhiều giao dịch EVM trên các rollup khác nhau, được thực thi nguyên tử. Nếu bất kỳ giao dịch nào thất bại, tất cả sẽ hoàn tác.

**RomulusTx** — Giao dịch EVM kết hợp + chỉ thị Solana gốc trong một thao tác nguyên tử. Loại mạnh nhất — kết hợp Solidity và Solana trong một giao dịch duy nhất.

## Tiếp theo là gì

* [Mô hình thực thi](/vi/cac-khai-niem-cot-loi/execution-model.md) — đi sâu vào cách giao dịch EVM thực thi trên Solana
* [Tương tác token](/vi/cac-khai-niem-cot-loi/token-interop.md) — cách ERC-20 và token SPL tương tác
* [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/bat-dau/key-concepts.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.
