> 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/how-it-works.md).

# Cách nó hoạt động

Theo dõi một block EVM qua việc đăng dữ liệu lên Solana, chứng minh ZisK và quyết toán cuối cùng.

Bộ sắp xếp của bạn nhận các giao dịch EVM qua JSON-RPC. Nó kiểm tra chữ ký, nonce, số dư và gas, rồi thực thi các giao dịch được chấp nhận theo thứ tự đến. Nó ghi các sub-block đã ký và các giao dịch của chúng vào một nhật ký có thứ tự bền vững trước khi trả về một xác nhận sơ bộ. Bộ sắp xếp nhúng reth để tạo ra các block của chuỗi.

Xác nhận sơ bộ cho bạn biết bộ sắp xếp đã chấp nhận và sắp xếp những gì. Nó không phải là một root cuối cùng trên Solana. Phần còn lại của đường đi công bố dữ liệu và chứng minh rằng việc thực thi nó cho ra trạng thái như đã được xác nhận.

```
Giao dịch EVM -> bộ sắp xếp -> nhật ký có thứ tự -> bộ tạo batch -> hộp thư đến Solana
Hộp thư đến Solana -> suy diễn -> reth-verifier -> khối + bằng chứng
khối + bằng chứng -> trình chứng minh (ZisK batch guest) -> bằng chứng + gốc
bằng chứng + gốc -> thanh toán trên Solana (PostRootProved) -> gốc cuối cùng
```

## Từ các block đến một batch inbox

Bộ tạo batch đọc các block liên tiếp từ nhật ký có thứ tự. Ví dụ `chain.toml` đóng một batch ở 60 block, hoặc 60 giây sau block đầu tiên của nó, tùy điều kiện nào đến trước. Nó nén batch thành các frame, đăng các frame dưới dạng các chunk inbox trên Solana, rồi hoàn tất cam kết Merkle của batch.

Cam kết inbox bao gồm ID của chuỗi và batch, slot mở đầu, số lượng chunk, root Merkle của các chunk và dải nạp của batch. Việc hoàn tất một batch inbox có nghĩa là dữ liệu của nó đã được đăng lên. Nó không làm cho state root của nó trở thành cuối cùng. Thẩm quyền của chuỗi ký xác nhận hoàn tất batch.

Bộ tạo batch không thể bỏ qua một số block. Việc thanh toán cũng lấy batch tiếp theo theo thứ tự. Đó là lý do một batch bị kẹt hoặc bị bỏ dở sẽ chặn các root sau đó. Bộ tạo batch tiếp tục một batch được ghi dở dưới cùng số đó sau khi khởi động lại khi nó có thể tái tạo lại nó.

## Suy diễn, xác minh và chứng minh

`suy diễn` đọc các batch inbox đã hoàn tất từ Solana. Nó tái tạo các block và điều khiển một `reth-verifier` node để thực thi lại chúng. Node này cung cấp các bằng chứng thực thi mà trình chứng minh batch cần và các bằng chứng trạng thái mà trình chứng minh thoát cần. Nó chạy API kiểm thử của reth, vì vậy nó phải nằm ngoài mạng công cộng.

Trình chứng minh đọc từng batch inbox đã hoàn tất, lấy các block và bằng chứng từ node xác minh, rồi chạy batch guest của chuỗi trong ZisK. Guest kiểm tra rằng các block khớp với dữ liệu inbox và thực thi đúng. Nó cam kết các giá trị công khai của batch, bao gồm cả state root thu được. Genesis và fee recipient của bạn được biên dịch vào guest này, vì vậy mỗi chuỗi có guest riêng và `programVK`.

Trình chứng minh kiểm tra bằng chứng cục bộ, rồi gửi `PostRootProved`. Chương trình thanh toán kiểm tra khóa xác minh đang hoạt động đã được đăng ký cho chuỗi này và bản phát hành ZisK được khóa đó chỉ định. Nó cũng kiểm tra các giá trị công khai của bằng chứng đối chiếu với ID chuỗi, phạm vi block, tiền nhiệm, cam kết inbox và root được tuyên bố.

Veritas là bộ xác minh của Rome cho các bằng chứng ZisK PLONK. Thanh toán liên kết mã xác minh của nó và chạy nó bên trong `PostRootProved`; nó không gọi chương trình Veritas được triển khai riêng. Một bằng chứng hợp lệ ghi một `Cuối cùng` root và đẩy đầu finality tiến lên trong cùng một giao dịch Solana. Root genesis của một chuỗi không cần cấp quyền tự nó không phải là cuối cùng. Root cuối cùng đầu tiên của nó cần một batch đã được chứng minh.

## Tài sản đi qua ranh giới

Một khoản nạp bắt đầu trên Solana. Chương trình cầu nối chuyển token đã nạp từ người nạp vào kho của chuỗi đó và nối thêm một bản ghi nạp có đánh số. Bộ sắp xếp đọc các khoản nạp Solana đã hoàn tất và ghi có vào địa chỉ EVM được nêu theo thứ tự. Bộ tạo batch cam kết phạm vi nạp cùng với batch. Số dư xuất hiện trên chuỗi khi block của nó được niêm phong, nhưng việc ghi có của nó chỉ là cuối cùng khi root của batch đó được chứng minh trên Solana.

Một lần rút bắt đầu trên chuỗi tại cổng thoát của nó. Cổng ghi lại một thông điệp và đốt tài sản gốc. Trình chứng minh thoát theo dõi thông điệp đó và lấy một bằng chứng lưu trữ Ethereum từ node xác minh đối chiếu với một root cuối cùng. Nó kiểm tra bằng chứng đó cục bộ, rồi gửi `ProveExit` đến thanh toán trên Solana.

Thanh toán kiểm tra cổng, thông điệp, root cuối cùng và mức trần thoát, đồng thời ngăn cùng một lối thoát bị chứng minh hai lần. Sau đó trình chứng minh thoát gửi giao dịch giải phóng của cầu nối. Cầu nối tiêu thụ lối thoát đã được chứng minh và trả tiền cho người nhận từ kho của chuỗi đó trong một giao dịch nguyên tử. Người nhận lấy từ bản ghi đã được chứng minh, nên người gửi lệnh giải phóng không thể thay đổi nó.

Đọc toàn bộ [kiến trúc v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.md) để biết các định dạng truyền tải, ranh giới giữa các thành phần và các kiểm tra trên từng lệnh.


---

# 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/how-it-works.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.