> 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/rome-zk-evm/releases.md).

# Phát hành

v0.3.0 bổ sung gì và cách một chuỗi chuyển giữa các bản phát hành chứng minh ZisK được hỗ trợ.

Phần này tài liệu hóa **Rome ZK EVM v0.3.0**. Hãy dùng mã nguồn v0.3.0 khớp, ảnh node và batch guest tương ứng. Guest sử dụng ZisK 1.3.1-alpha. Thẻ phát hành đặt tên cho cây mã nguồn được dùng cho ảnh. Nhánh `chính` có thể đã thay đổi kể từ bản phát hành.

Các [nhật ký thay đổi đầy đủ v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/CHANGELOG.md#v030) ghi lại các lệnh, bản sửa và giới hạn phía sau bản phát hành.  [chính sách phát hành ZisK](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ZISK-RELEASES.md) mô tả sổ đăng ký trên chuỗi và quy trình di chuyển.

## Trong v0.3.0

các chuỗi Devnet giờ đây có thể nhận tiền gửi và chi trả rút tiền từ chính các kho wrapped SOL của chúng. Cơ quan quản lý chuỗi có thể mở hàng đợi tiền gửi, đặt giới hạn và phí của nó, rồi thay đổi chúng sau khi kích hoạt trễ. Sequencer ghi có các khoản tiền gửi Solana đã được hoàn tất trong các block EVM; batcher cam kết phạm vi đã sắp xếp của chúng vào batch inbox.

Ảnh node bao gồm một bộ chứng minh lối ra. Với `EXITS=on`, nó theo dõi cổng lối ra của chuỗi, chứng minh việc rút tiền dựa trên các gốc Solana cuối cùng, và tự gửi việc giải phóng vault. Nó dùng payer riêng của nó. Theo mặc định, một khoản chi nhỏ tới người nhận không có tài khoản token wrapped SOL sẽ chờ giải phóng thủ công. `./rollup check` báo cáo cấu hình lối ra, tình trạng dịch vụ, các lối ra bị kẹt và số dư payer lối ra.

Các bằng chứng dùng ZisK 1.3.1-alpha. Settlement và Veritas giờ đây giữ một khóa xác minh và gốc đệ quy được ghim cho mỗi bản phát hành ZisK. Thiết lập máy chủ prover tải xuống và kiểm tra các kho lưu trữ khóa của bản phát hành này, kiểm tra các binary GPU và chuẩn bị các tệp hằng số dùng cho việc hợp nhất. Bản phát hành này cũng thêm các biểu mẫu issue yêu cầu khóa xác minh và báo lỗi.

Hướng dẫn devnet liên kết các giao dịch explorer từ lượt chạy riêng của Rome, từ đăng ký đến chi trả. Bản phát hành này vẫn để lại các tài khoản inbox batch và chunk cũ mở. Các tài khoản pending-root vẫn mở theo mặc định; tiền thuê của chúng tiếp tục tích lũy. Rome vẫn chưa quyết định dữ liệu batch cũ phải ở lại trên Solana bao lâu.

## Các bản phát hành ZisK thuộc về khóa

Mỗi chuỗi có một sổ đăng ký khóa xác minh. Một mục chứa `programVK`, một bố cục giá trị công khai, một slot kích hoạt và một số scheme. Con số đó đặt tên cho bản phát hành ZisK được dùng để xây dựng guest và khóa; bằng chứng không tự chọn bản phát hành của nó. Sổ đăng ký có bốn ô mục.

| Scheme | Bản phát hành ZisK | Trạng thái v0.3.0                             |
| ------ | ------------------ | --------------------------------------------- |
| `1`    | `1.2.0-alpha`      | Đã rút; các bằng chứng của nó bị từ chối.     |
| `2`    | `1.3.1-alpha`      | Mở; các mục mới và bằng chứng được chấp nhận. |

Settlement tra cứu mục đang hoạt động khớp với `programVK`. Mục đó chọn khóa Veritas của bản phát hành đó và gốc đệ quy được ghim. Một bằng chứng có gốc sai sẽ bị từ chối trước các kiểm tra giá trị công khai và ghép cặp. Một bản phát hành đã rút không còn khóa xác minh nào trong bản dựng production.

## Di chuyển một chuỗi sang bản phát hành mới

Cài đặt chuỗi công cụ ZisK mới và các khóa chứng minh mới, đồng thời vẫn giữ bản cài đặt cũ sẵn dùng. Đặt cùng nhau thẻ nguồn rollup, thẻ guest và bản phát hành ZisK, rồi chạy `./rollup guest-build` để xây dựng một guest mới và `programVK` cho cùng genesis. Trình prover cần bản cài đặt ZisK, guest và siêu dữ liệu xác minh khớp.

Gửi cho Rome genesis của chuỗi, thẻ guest, hàm băm ELF và `programVK`. Rome dựng lại và kiểm tra guest rồi đăng ký khóa mới với một slot kích hoạt trong tương lai. Nếu chuỗi đã đăng một root, Rome cũng cần guest và bản phát hành trước đó. Hãy kiểm tra mục on-chain mới và slot kích hoạt, rồi chuyển sang prover khi slot đó đến. Rome sẽ loại bỏ mục cũ sau khi chuyển. Một mục trong tương lai không thể xác minh sớm.

Chính sách hỗ trợ của Rome giữ tối đa hai bản phát hành ZisK mở cùng lúc. Một bản phát hành đang đóng không chấp nhận mục mới, nhưng các mục hiện có vẫn có thể xác minh trong khi các chuỗi di chuyển. Khi Rome thông báo một bản phát hành sắp đóng, các chuỗi trên devnet và testnet có 30 ngày để di chuyển. Khoảng thời gian đó là chính sách hỗ trợ của Rome, không phải bộ đếm thời gian trên chuỗi. Rome có thể loại bỏ ngay các mục vì một việc rút vì lý do bảo mật. Một bản phát hành đã rút không chấp nhận cả mục mới lẫn bằng chứng, vì vậy một chuỗi vẫn ở 1.2.0-alpha cần một mục 1.3.1-alpha đang hoạt động trước khi có thể đăng một root khác.


---

# 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/rome-zk-evm/releases.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.