> 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/constraints.md). # Ràng buộc Các giới hạn khi xây dựng trên Rome EVM — kích thước giao dịch Solana, ngân sách \~1,4M CU, giới hạn account, bố cục lưu trữ, và cách Rome xử lý từng giới hạn. Các giới hạn và ranh giới quan trọng khi xây dựng trên Rome EVM. Hiểu rõ các ràng buộc này giúp bạn thiết kế các hợp đồng hoạt động đáng tin cậy. ## Giới hạn giao dịch Solana | Ràng buộc | Giá trị | Tác động | | -------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Kích thước giao dịch | 4 KB (4.096 byte) | Rome gửi các giao dịch Solana v1; các giao dịch EVM lớn hơn được tạm lưu trong các tài khoản giữ hộ (minh bạch) | | Số đơn vị tính toán mỗi giao dịch | \~1,4 triệu CU | Các thao tác vượt quá mức này sẽ dùng chế độ lặp, vốn có các giới hạn riêng (bên dưới) | | Số tài khoản mỗi giao dịch | 64 địa chỉ | Giới hạn giao dịch v1; mọi thứ mà giao dịch EVM và các CPI của nó chạm tới, bao gồm cả các tài khoản của Rome, đều được tính | | Kích thước tối đa của tài khoản giữ hộ | 80 KB | Kích thước RLP tối đa cho một giao dịch EVM đơn lẻ | ## Giới hạn thực thi EVM | Ràng buộc | Giá trị | Ghi chú | | ----------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Các ô lưu trữ hợp đồng | 256 cho mỗi tài khoản lưu trữ | Có thể tạo nhiều tài khoản lưu trữ cho mỗi hợp đồng | | Số opcode mỗi vòng lặp | Thích ứng | Được đóng gói vừa với ngân sách CU của mỗi giao dịch Solana (VmIt) | | TTL khóa tài khoản | 3 giây (4 giây khi phiên chạm tới hơn 28 tài khoản) | Trong quá trình thực thi lặp; được gia hạn ở mỗi bước | | Độ dài phiên lặp | 160 bước | Khi vượt quá giới hạn, bước tiếp theo sẽ giải phóng các khóa của phiên và kết thúc mà không ghi nhận gì | | Các chặng được Rust Rome SDK lập kế hoạch | 128 | Ngưỡng tối đa của trình hợp thành lặp; các lệnh thực tế hoàn tất với ít hơn nhiều | | Số giao dịch trên mỗi kế hoạch do ví ký | 64 | Nhiều nhất là `rome_submitSignedV1Plan` chấp nhận trong một lệnh gọi; xem [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) | | Ví ngân quỹ | 64 | Ví quỹ phí | | Giới hạn kích thước hợp đồng | 24 KB | Giống Ethereum (EIP-170, 24.576 byte) | ## Ràng buộc CPI | Ràng buộc | Giá trị | Ghi chú | | ----------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Độ sâu CPI | Tối đa 4 cấp | Giới hạn độ sâu CPI của Solana | | Số tài khoản mỗi lệnh gọi CPI | Nằm trong giới hạn 64 địa chỉ của giao dịch | Được chia sẻ với mọi tài khoản khác mà giao dịch chạm tới | | Độ sâu CPI + Transfer Hook | Dùng các cấp CPI | Các transfer hook từ bên trong CPI có thể vượt quá độ sâu | | Một luồng cho mỗi hợp đồng | Cũ (`0xff…07/08/09`, `0x42…16`) **hoặc** được lưu đệm (`0xff…04/05/06/0b`) | Việc trộn các lệnh gọi thay đổi từ cả hai trong một giao dịch sẽ bị từ chối | | CPI kiểu cũ trong chế độ lặp | Không được phép | Một CPI theo luồng cũ trong giao dịch lặp sẽ lỗi với `CpiProhibitedInIterativeTx`; các hiệu ứng của luồng được lưu đệm được phép | **Độ sâu CPI là ràng buộc quan trọng nhất.** Rome EVM tiêu thụ một cấp CPI khi Solana gọi chương trình Rome. Nếu hợp đồng Solidity của bạn sau đó gọi một chương trình Solana khác qua CPI, đó là cấp 2. Nếu chương trình đó gọi thêm một chương trình khác, đó là cấp 3. Tổng cộng bạn chỉ có tối đa 4 cấp. ``` Cấp 0: Solana Runtime → Chương trình Rome EVM Cấp 1: Chương trình Rome EVM → đích CPI của bạn (ví dụ: Jupiter) Cấp 2: Jupiter → chương trình khác (ví dụ: Raydium) Cấp 3: Raydium → SPL Token (độ sâu tối đa) ``` ## Ràng buộc Transfer Hook của Token-2022 | Ràng buộc | Tác động | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Một hook cho mỗi mint | Một mint Token-2022 chỉ có một vị trí transfer-hook | | `transfer_checked` chỉ | Các hook không kích hoạt trên lệnh chuyển thông thường `chuyển`. Các thao tác cầu nối của Rome sử dụng `transfer_checked` | | Mint/burn không được hook | Được kiểm soát qua quyền mint, không phải hooks | ## Ràng buộc về gas và định giá | Ràng buộc | Ghi chú | | ------------------ | ------------------------------------------------------------------- | | Nguồn định giá gas | pool Meteora DAMM, v1 hoặc v2 (token gas SPL) | | Hệ số nhân giá gas | Có thể cấu hình theo proxy (`gas_price_mul`) | | Giá gas tối thiểu | Được đặt bởi cấu hình proxy | | Ước tính gas | Được thực hiện ngoài chuỗi qua trình mô phỏng Mollusk trước khi gửi | ## Ràng buộc theo mạng | Môi trường | Mã Chain | ID chương trình rome-evm | | ----------------- | -------- | --------------------------------------------- | | Hadrian (testnet) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Rubicon (mainnet) | 7531 | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` | ## Ràng buộc precompile | Precompile | Ràng buộc | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Modexp (0x05) | **Bị vô hiệu hóa** — một lệnh gọi sẽ hoàn nguyên với `lệnh gọi big_mod_exp bị vô hiệu hóa` cho đến khi Solana kích hoạt `big_mod_exp` syscall | | BN254 ecPairing (0x08) | Khoảng 22K CU cộng thêm 12.8K mỗi cặp theo cách định giá của chương trình; một phép kiểm tra bốn cặp vừa trong một giao dịch nguyên tử | | CPI precompile (0xFF...08) | Các tài khoản phải được khai báo trước trong giao dịch Solana | ## Xác thực giao dịch | Quy tắc | Hiệu lực | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Tính biến dạng chữ ký (EIP-2) | Một giao dịch đã ký mà `s` nằm trên nửa bậc của đường cong sẽ bị từ chối | | Dạng RLP | Một giao dịch có danh sách RLP chứa các byte thừa sau mục cuối cùng sẽ bị từ chối | | Opcode chưa được triển khai | Hủy toàn bộ giao dịch (`IncompatibleVersionEVM(opcode)`); không có gì được ghi nhận và một hợp đồng gọi không thể nuốt lỗi này | | Đo đếm gas | Rome không có lịch gas theo từng opcode: lượng gas truyền đến `CALL`/`CREATE` không được cưỡng chế, và không có khoản cấp 2300 gas — đừng dựa vào bảo vệ tái nhập dựa trên stipend | ## Ràng buộc Oracle | Ràng buộc | Giá trị | | --------------------------- | ------------------------------------------------------------------------- | | Độ lỗi thời tối đa mặc định | 60 giây | | Dữ liệu vòng lịch sử | Không được hỗ trợ — `getRoundData(roundId)` hoàn nguyên | | EMA của Switchboard | Không được hỗ trợ — `latestEMAData()` hoàn nguyên trên SwitchboardV3 | | Độ lệch parser | Đã được xác thực thực nghiệm — phải xác thực lại trước khi triển khai lại | ## Khuyến nghị thiết kế 1. **Giữ độ sâu CPI nông.** Thiết kế hợp đồng để giảm thiểu lồng nhau. Nếu bạn gọi Jupiter, rồi Jupiter gọi Raydium, rồi Raydium gọi SPL Token, bạn đang ở cấp 3 — cực kỳ sát giới hạn. 2. **Ưu tiên chế độ nguyên tử.** Thiết kế các thao tác để vừa trong \~1,4 triệu CU. Chế độ lặp làm tăng độ trễ (khóa 3-4 giây), giới hạn 160 vòng lặp mỗi phiên, và một lời nhắc ví cho mỗi chặng trên làn Solana khi ví tự ký các chặng. Một lệnh gọi tạo ra CPI theo luồng cũ thì hoàn toàn không thể chạy ở chế độ lặp. 3. **Khai báo tài khoản trước.** Tất cả các tài khoản Solana được CPI chạm tới phải được biết tại thời điểm tạo giao dịch (phần mô phỏng của proxy sẽ phát hiện chúng). Không thể khám phá tài khoản động trong một lệnh gọi CPI, và tổng số phải vừa với giới hạn 64 địa chỉ. 4. **Chọn một luồng precompile cho mỗi hợp đồng.** Gọi một chương trình Solana tùy chỉnh (`invoke_signed`) là luồng cũ và chỉ nguyên tử; xem [Tích hợp một chương trình Solana](/vi/huong-dan-cho-nha-phat-trien/integrate-solana-program.md). 5. **Sử dụng `transfer_checked`.** Nếu bạn đang xây dựng bất cứ thứ gì chạm tới token Token-2022, hãy luôn dùng `transfer_checked` để đảm bảo các hook được kích hoạt. 6. **Kiểm tra mức tiêu thụ CU.** Đo các đơn vị tính toán Solana thực tế từ biên lai giao dịch (`computeUnitsConsumed`) — EVM `gasUsed` không phải là đại diện trung thực cho CU của Solana. Tối ưu bằng Yul cho các đường nóng. ## 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 chi tiết cho mỗi thao tác * [Tương tác token](/vi/cac-khai-niem-cot-loi/token-interop.md) — mô hình cầu nối ERC-20 ↔ SPL * [Tài liệu tham chiếu precompile](/vi/tai-lieu-tham-khao/precompiles.md) — mọi selector và lớp dispatch của 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/cac-khai-niem-cot-loi/constraints.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.