> 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/ung-dung-tren-rome/bloom/lanes.md).

# Hai làn

Một lần triển khai token, hai thế giới ví. Cả hai luồng đều thực thi **cùng các hợp đồng** với **cùng cổng kiểm soát tuân thủ** — chúng chỉ khác nhau ở chỗ ai ký và giao dịch đến chuỗi như thế nào.

## Luồng EVM

Bộ công cụ Ethereum tiêu chuẩn, không thay đổi: ví ký một giao dịch EVM, điểm cuối JSON-RPC của chuỗi chấp nhận nó, hợp đồng token thực thi danh sách cho phép. Không có gì đặc thù Bloom để tích hợp.

Gas Rome được tính bằng USDC, và một lệnh ghi tốn nhiều hơn bản tương đương trên Ethereum bất cứ khi nào nó phải tạo tài khoản Solana (người nắm giữ lần đầu, tài khoản token mới). Hãy dùng `eth_estimateGas`, như các công cụ tiêu chuẩn vẫn làm, và đừng bao giờ mã hóa cứng 21.000; ước tính đã bao gồm việc tạo tài khoản, và Rome tính gas theo mức thực tế đã dùng. Một chuyển khoản có cổng kiểm soát cũng phải trả cho bước kiểm tra allowlist, nên nó tốn hơn một chuyển khoản thường cùng kích thước.

## Solana

Một ví Solana điều khiển các hợp đồng EVM giống nhau **một cách nguyên bản — không có khóa EVM nào tồn tại ở bất kỳ đâu**. Mỗi lệnh gọi là một giao dịch Solana v1 mà proxy của chuỗi ghép lại để ví ký. Không có bảng tra cứu địa chỉ và cũng không có chỉ thị ngân sách tính toán nào cần tạo: proxy tự đặt ngân sách tính toán và heap.

1. **Danh tính.** Địa chỉ phía EVM của người dùng là *tổng hợp*: được suy ra một cách xác định như `keccak256(solana_pubkey)[12..32]`. Chương trình Rome EVM suy ra nó on-chain từ bên ký thực sự của giao dịch — không thể giả mạo, và cũng không tồn tại khóa riêng secp256k1 cho nó, vì vậy **chữ ký Solana là thứ duy nhất có thể điều khiển địa chỉ này**.
2. **Ủy quyền.** Ứng dụng dựng lệnh gọi thành một payload EIP-1559 chưa ký, dùng nonce, giá gas và ước tính gas nó đọc từ chuỗi. Ví ký một thông điệp dễ đọc — nó hiển thị dưới dạng *Rome authorization* theo sau là một hash của lệnh gọi — điều đó chứng minh khóa Solana cho phép payload EVM chính xác này. Đây là lời nhắc đầu tiên, và proxy sẽ không ghép lệnh gọi nếu thiếu nó.
3. **Ghép.** Ứng dụng gửi payload và chữ ký đó tới proxy. Proxy kiểm tra chữ ký, mô phỏng lệnh gọi để tìm xem nó chạm đến những tài khoản Solana nào và tài khoản nào có thể ghi, rồi trả về một giao dịch Solana v1. Ứng dụng kiểm tra thông điệp được trả về trước khi yêu cầu ví ký nó.
4. **Ký và gửi.** Ví tự ký giao dịch: lời nhắc thứ hai, một chữ ký khác trên một chuỗi byte khác. Ứng dụng gửi trực tiếp giao dịch đã ký tới Solana RPC; người dùng trả phí Solana bằng SOL từ chính ví của họ.
5. **Xác nhận.** Giao dịch được xác nhận trên Solana; chế độ xem EVM cập nhật chậm hơn một nhịp, nên ứng dụng chờ nonce của địa chỉ tổng hợp thay đổi trước khi gửi lệnh gọi tiếp theo.

**Ví phải ký các giao dịch Solana v1.** Luồng này sẽ fail-closed nếu thiếu điều đó: ví không thể ký giao dịch v1 thì lệnh gọi dừng lại với lỗi, và ứng dụng không bao giờ quay về định dạng giao dịch cũ hơn. Solflare hiện ký v1 trên devnet; Phantom thì chưa.

### Trước lệnh gọi: tiền mặt và quyền cấp một lần

Có hai thứ có thể diễn ra trước một lệnh gọi ở luồng Solana, và mỗi thứ xuất hiện như một bước riêng với các lời nhắc riêng:

* **Nạp tiền vào.** Một lệnh gọi chi tiêu wUSDC sẽ rút từ địa chỉ tổng hợp, nơi khi ở trạng thái nghỉ thì không giữ gì. Nếu số dư của địa chỉ tổng hợp ít hơn mức lệnh gọi cần, ứng dụng trước tiên chuyển phần thiếu từ tài khoản token USDC của chính ví sang tài khoản của địa chỉ tổng hợp. Đây là một giao dịch Solana được ký bằng một lời nhắc, không phải lệnh gọi EVM: tạo idempotent tài khoản token của địa chỉ tổng hợp, rồi chỉ thị activate-token-account của chương trình Rome, chỉ thị này chuyển token mà không chạy EVM. Bước này bị bỏ qua khi địa chỉ tổng hợp đã giữ đủ.
* **Quyền cấp wrapper một lần.** wUSDC là lớp bọc của một token SPL, và một lớp bọc di chuyển token của người dùng với tư cách là ủy quyền SPL của người dùng đó. Lần đầu địa chỉ tổng hợp của một ví chi tiêu wUSDC, quyền cấp chưa được thiết lập, và ứng dụng thêm một **Cho phép chuyển wUSDC** bước ở trước các bước còn lại. Đó là một lệnh gọi như bao lệnh khác (hai lời nhắc), một lần cho mỗi ví. Xem [Cấp quyền một lần cho mỗi ví](/vi/cac-khai-niem-cot-loi/token-interop.md#one-time-grant-per-wallet).

Vì vậy, một lần mua từ một ví Solana mới sẽ là một chuỗi ngắn: nạp tiền vào, cho phép chuyển wUSDC, phê duyệt cửa hàng, mua.

### Các lệnh gọi quá lớn cho một giao dịch

Một giao dịch Solana nguyên tử có các ngưỡng cố định: khoảng 1,4M compute unit, 64 tài khoản và 4 KB trên đường truyền (xem [Ràng buộc](/vi/cac-khai-niem-cot-loi/constraints.md)). Bloom luôn thử trước giao dịch ký trực tiếp bởi ví. Chỉ khi proxy từ chối lệnh gọi vì nó không vừa trong một giao dịch thì ứng dụng mới chuyển nó cho proxy để **chuyển tiếp**, và không bao giờ trước đó:

* **Một lời nhắc cho lệnh gọi đó.** Cơ chế chuyển tiếp tái sử dụng thông điệp ủy quyền mà ví đã ký cho lần thử bị từ chối, nên không có lời nhắc giống hệt lần thứ hai và cũng không có giao dịch nào để ký. Proxy ghép lệnh gọi, gửi nó lên Solana (trong bao nhiêu giao dịch tùy cần) và tự trả phí Solana.
* **Gas Rome lấy từ số dư của địa chỉ tổng hợp.** Một lệnh gọi được chuyển tiếp được thanh toán bằng gas gốc của chuỗi, tính bằng wei, từ địa chỉ tổng hợp. Nếu số dư đó không đủ chi phí của lệnh gọi, ứng dụng trước tiên nạp thêm từ ví, theo đơn vị nguyên 10^12 wei: thêm một lời nhắc nữa, thường chỉ một lần cho mỗi ví, giống như quyền cấp.
* **Hash đó là hash giao dịch Rome.** Kết quả của một lệnh gọi được chuyển tiếp là hash giao dịch EVM của proxy, không phải chữ ký Solana, nên nó sẽ không mở được trên trình khám phá Solana; hãy tra trên trình khám phá của chính chuỗi.

Cơ chế chuyển tiếp áp dụng cho bất kỳ lệnh gọi nào mà proxy báo là quá lớn cho một giao dịch, trong Credit có thể bao gồm các hành động thị trường lớn hơn. Phần lớn lệnh gọi, gồm cả chuyển khoản thường và phê duyệt, vừa trong một giao dịch và không bao giờ đi theo đường này. Cơ chế của các lệnh gọi được chuyển tiếp và các giới hạn của chúng nằm trong [Các lệnh gọi được chuyển tiếp và lệnh gọi dài](/vi/huong-dan-cho-nha-phat-trien/call-evm-from-solana.md#relayed-calls-and-long-calls).

### Số lời nhắc mỗi bước

| Bước                                                                | Lời nhắc ví                                            |
| ------------------------------------------------------------------- | ------------------------------------------------------ |
| Nạp tiền vào (chỉ khi thiếu)                                        | 1                                                      |
| Cho phép chuyển wUSDC (một lần cho mỗi ví)                          | 2                                                      |
| Một lệnh gọi vừa trong một giao dịch (phê duyệt, mua, chuyển khoản) | 2: thông điệp ủy quyền, rồi đến giao dịch              |
| Một lệnh gọi phải được chuyển tiếp                                  | 1, cộng thêm 1 cho lần nạp gas một lần nếu số dư thiếu |

Trên trang tài sản Invest, một ví Solana đi qua các bước nạp tiền, cấp quyền, phê duyệt và mua trong một lượt sau khi bấm Buy, và nút sẽ ghi "hai lời nhắc ví" trong khi từng bước ký. Các bước được nêu tên ("Chuyển tiền mặt của bạn") và số lời nhắc ban đầu được hiển thị trên Trade và Credit. Một ví EVM cũng nhận một bước một lần *Cho phép chuyển wUSDC* bước trên bảng mua.

### Compute được đo, từ luồng trước

Trước khi chuyển sang giao dịch v1, luồng này tự dựng giao dịch của nó và đo các số liệu này trên Rome devnet, với các khoảng quan sát được trên hai chuỗi. Chúng chưa được đo lại trên giao dịch v1 mà proxy hiện ghép, vì vậy hãy coi chúng là mức bậc độ lớn, không phải ngân sách:

| Luồng Solana                                                   | CU         |
| -------------------------------------------------------------- | ---------- |
| Chuyển RWA có cổng kiểm soát                                   | \~339–381K |
| Phê duyệt wUSDC                                                | \~189–191K |
| Mua trên storefront (phê duyệt + mua, hai giao dịch)           | \~730–796K |
| Quét phần tiền mặt vào tài khoản token của chính ví            | \~42–54K   |
| Chuyển giá trị thường                                          | \~47K      |
| `TestApprover.approve` — chấp nhận vào allowlist, **do ví ký** | 220,794    |

Ngưỡng compute cho mỗi giao dịch của Solana là 1,4M CU. Hãy đo lệnh gọi của bạn từ `meta.computeUnitsConsumed` (`getTransaction` trên một Solana RPC; biên lai EVM của chuỗi không có trường như vậy) thay vì mặc định lấy một trong các mức này.

## Quyền lưu ký: vì sao RWA ở lại tại địa chỉ tổng hợp

Câu hỏi thiết kế mà mọi tài sản có cấp phép phải trả lời: *token có thể rò rỉ ra ngoài vành đai tuân thủ không?* Trên luồng Solana, câu trả lời mang tính cấu trúc, không phải chính sách:

* **RWA cư trú trong trạng thái EVM.** Số dư của nó là bộ nhớ lưu trữ bên trong các tài khoản của chương trình Rome EVM. Không có **SPL mint** bản thể token account nào của nó, không có đại diện tài khoản token, không có gì nguyên bản Solana để di chuyển. (Điều này là có chủ ý — một phiên bản bọc/nhân bản sẽ là lối thoát.)
* **Phần hạ tầng phía Solana không thể chạm vào nó.** Các phần di chuyển tài sản của luồng (`create_ata`, chuyển SPL, quét) hoạt động trên tài khoản token SPL; số dư lưu trữ EVM không có loại tài khoản như vậy. Không có chỉ thị nào chuyển số dư EVM sang tài khoản token Solana.
* **Chỉ chữ ký Solana của chủ sở hữu mới điều khiển địa chỉ tổng hợp**, và mọi di chuyển mà nó có thể biểu đạt đều là một lệnh gọi vào hợp đồng token — hợp đồng này chạy cổng allowlist — nên một chuyển khoản tới địa chỉ không nằm trong whitelist sẽ bị hoàn nguyên giống hệt nhau dù được ký bởi khóa EVM hay khóa Solana.
* **Phần tiền mặt là ngoại lệ có chủ ý.** wUSDC (lợi suất, tiền thu từ bán) được bảo chứng bởi SPL và *nên* đi khứ hồi: nhánh thoát (`transfer_spl`) chuyển nó từ địa chỉ tổng hợp sang tài khoản token liên kết của chính ví, được xác minh đầu-cuối. Tài sản ở lại trong vành đai; tiền mặt lưu chuyển tự do.

Hai hệ quả thực tế, nói thẳng: giao diện ví Solana sẽ không hiển thị khoản nắm giữ RWA (không có token SPL nào để liệt kê) — ứng dụng Bloom là bề mặt hiển thị vị thế; và một khóa Solana bị mất sẽ được khôi phục thông qua quy trình của bên phát hành ([COMPLIANCE.md](/vi/ung-dung-tren-rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), chứ không phải bằng cách di chuyển tài sản ra ngoài kênh — và đó chính là thuộc tính mà một tài sản có cấp phép mong muốn.


---

# 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/ung-dung-tren-rome/bloom/lanes.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.