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

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

Theo dõi một block Ostia từ reth qua quá trình chứng minh đến commit Canton của nó.

Mỗi lần builder chạy sẽ tạo, chứng minh và gửi một khối. Canton quyết định liệu khối đó có trở thành head tiếp theo của chuỗi hay không. Một khối EVM và các leg của Canton mà nó ghi lại được xác nhận trong cùng một giao dịch.

Trang này mô tả commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Đọc toàn bộ [thiết kế](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md).

```mermaid
flowchart TD
    W["Giao dịch EVM"] --> R["reth tạo khối theo yêu cầu"]
    R --> B["Builder đọc các leg của gateway và tìm các hợp đồng Canton của chúng"]
    B -->|"Một leg không thể được thanh toán: loại giao dịch của nó ra và xây dựng lại"| R
    B -->|"Mọi leg đều có thể được thanh toán"| P["ZisK chứng minh khối"]
    P --> A["Tiến hành: khối, bằng chứng và các leg trong một giao dịch Canton"]
    A --> S["Lệnh gọi ngoài: sidecar kiểm tra bằng chứng và trạng thái gateway"]
    S --> D["Daml kiểm tra head và thanh toán các leg"]
    D --> C["Canton xác nhận khối và các leg của nó cùng nhau"]
    C --> F["reth đánh dấu khối là cuối cùng"]
```

## Xây dựng trên head của Canton

Ví gửi giao dịch EVM đến reth. Trình khởi chạy được cung cấp giữ cho việc khám phá peer ở trạng thái tắt. reth tạo một khối khi builder yêu cầu một khối.

Builder trước hết đọc phần đang hoạt động `ZkChain` hợp đồng trên Canton. Nó chuyển head, block an toàn và block đã hoàn tất của reth đến head đã được xác nhận đó. Nó chọn các giao dịch đang chờ theo giá, giữ đúng thứ tự nonce của từng người gửi và nằm trong giới hạn gas. Nó yêu cầu reth tạo khối với danh sách giao dịch cụ thể đó.

Một giao dịch EVM cần một hành động Canton sẽ gọi gateway. Gateway ghi lại một leg và gộp nó vào một hàm băm đang được tích lũy cho khối. Builder đọc các sự kiện của gateway theo thứ tự log và tìm các hợp đồng Canton mà mỗi leg cần.

Nếu một phân bổ không còn nữa, một bên nhận chưa chấp nhận các khoản rút, hoặc một hợp đồng bắt buộc khác bị thiếu, builder sẽ loại giao dịch đó và các giao dịch sau đó của người gửi đó. Nó đưa reth trở lại head của Canton và xây dựng lại. Các kiểm tra này diễn ra trước khi chứng minh. Phần [README của trình dựng](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) liệt kê các kiểm tra cho từng leg.

## Chứng minh khối

Builder lưu khối và bằng chứng thực thi của reth. Công cụ đầu vào kết hợp khối, bằng chứng và genesis thành đầu vào cho prover. ZisK chạy guest, thứ xác thực khối theo các quy tắc cố định của chuỗi.

Prover trả về một bằng chứng được bao bọc kích thước 1.344 byte, gắn với hàm băm của khối. Builder gửi `Tiến hành` kèm theo header, các giao dịch, bằng chứng, các leg và các bằng chứng tài khoản và lưu trữ của gateway tại gốc trạng thái của khối.

## Kiểm tra và thanh toán trong một giao dịch

Mỗi người tham gia xác nhận chạy một sidecar. Lệnh gọi ngoài của Canton gửi khối đến sidecar của người tham gia đó để `xác minh`. Nó kiểm tra bằng chứng, khóa chương trình được ghim và bản phát hành ZisK, hàm băm của header và root của danh sách giao dịch.

Daml đối chiếu câu trả lời với `ZkChain`: parent phải là head hiện tại, số phải là số kế tiếp, và gas limit cùng gas used phải nằm trong giới hạn. Daml so sánh các câu trả lời của sidecar; nó không tự kiểm tra bằng chứng không kiến thức.

Sau đó Daml ghi một dòng cho mỗi leg từ các hợp đồng Canton mà nó nêu tên. id, burner và amount của một khoản rút tiền đến từ builder; hàm băm đã được chứng minh ràng buộc chúng với những gì khối đã ghi lại. Phần của sidecar `các phần` hàm kiểm tra các bằng chứng tài khoản và lưu trữ của gateway, băm các dòng đó theo thứ tự và so sánh kết quả với giá trị của gateway trong trạng thái đã được chứng minh. Một khối không có leg phải vượt qua cùng kiểm tra đó với danh sách rỗng.

Daml thanh toán các leg theo thứ tự và tạo ra `BlockRecord` và tiếp theo `ZkChain`. Canton xác nhận các thay đổi này cùng nhau. Nếu một kiểm tra hoặc thanh toán thất bại, sẽ không có gì được xác nhận. Việc tiêu thụ một hợp đồng trạng thái duy nhất của chuỗi khiến Canton trở thành cơ quan có thẩm quyền về thứ tự khối. Xem đầy đủ [giao diện Daml](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) và [các kiểm tra sidecar](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md).

## Khi Canton từ chối

Sau khi Canton xác nhận khối, builder đánh dấu nó là cuối cùng trong reth. Nếu Canton từ chối nó, builder đưa reth trở lại khối đã xác nhận gần nhất của Canton và gửi các giao dịch của khối bị từ chối trở lại pool. Lần chạy tiếp theo sẽ kiểm tra lại các leg của chúng. Một khoản thanh toán có phân bổ đã bị thu hồi sẽ bị loại ra.

Nếu builder mất phản hồi khi gửi, nó đọc lại head của Canton để xác định liệu khối đã được xác nhận hay chưa. Nếu lần đọc đó cũng thất bại, nó báo cáo một kết quả không xác định và giữ reth ở nguyên vị trí. Lần chạy tiếp theo bắt đầu từ head của Canton. Các quy tắc khôi phục này nằm trong [README của trình dựng](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#what-one-run-does).


---

# 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/canton-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.