> 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/prover-host.md).

# Máy chủ prover

Yêu cầu máy chủ của trình chứng minh, worker bền vững và bản dựng guest được ghim.

Trình tạo bằng chứng chạy ZisK với một worker GPU. Bộ điều phối và worker vẫn chạy giữa các yêu cầu, với khóa PLONK đã được nạp sẵn. Với mỗi khối, trình tạo gửi đầu vào và nhận về một bằng chứng đã được bọc.

Trang này mô tả commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Đọc toàn bộ [README của prover](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/prover/README.md) và [thông số đo](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md).

## Yêu cầu hệ thống

Trình cài đặt nhắm đến Linux x86-64 với `apt`, `sudo`, một trình điều khiển NVIDIA đã cài đặt và khoảng 100 GB dung lượng đĩa trống. Nó cài đặt các gói hệ thống và thay đổi giới hạn khóa bộ nhớ.

Bài kiểm tra hiệu năng ngày 2026-10-03 đã sử dụng một NVIDIA RTX PRO 6000 Blackwell Server Edition với 96 GB bộ nhớ GPU, 48 vCPU trên một AMD EPYC 9B45, và 176 GiB RAM của máy chủ. Hệ thống chạy Ubuntu 22.04.5 với driver 580.178.04. Các thông số này mô tả máy đã được kiểm thử; chúng không xác định phần cứng tối thiểu cần để chạy prover.

Bài kiểm tra hiệu năng ghi nhận 22,9 GiB bộ nhớ chia sẻ của trình giả lập. Riêng phần bọc PLONK báo cáo yêu cầu GPU là 30.054.767.337 byte, khoảng 28,0 GiB. Mức sử dụng bộ nhớ GPU cao nhất là 93,2 GiB, nhưng prover cấp một bộ đệm lớn cho card. Mức đỉnh đó phản ánh việc cấp phát bộ đệm và không cho thấy toàn bộ prover cần bao nhiêu bộ nhớ GPU ở mức tối thiểu. Xem [Các phép đo](/vi/canton-zk-evm/measurements.md) để biết phạm vi của từng con số.

## Biên dịch và chạy

Các script sử dụng các phiên bản trong [GHIM](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). Prover sử dụng ZisK 1.3.1-alpha, Node 20.20.2 và snarkjs 0.7.6. Phiên bản Node của explorer là riêng biệt.

| Script                  | Nó làm gì                                                                                                         |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `prover/install.sh`     | Kiểm tra mã kiểm tra đã ghim của trình cài đặt, sau đó cài đặt bản build GPU, khóa chứng minh và thiết lập PLONK. |
| `prover/build-guest.sh` | Biên dịch ELF của guest và in SHA-256, programVK, rootC và mã băm rules của nó.                                   |
| `prover/start.sh`       | Khởi động bộ điều phối và một worker GPU với khóa PLONK đã được nạp.                                              |
| `prover/make-input.sh`  | Chuyển một khối đã lưu, bằng chứng thực thi và genesis thành đầu vào cho prover.                                  |
| `prover/prove-one.sh`   | Chứng minh một đầu vào, kiểm tra bằng chứng bằng `cargo-zisk`, và ghi bằng chứng đã bọc dưới dạng hex.            |

`ZISK_COORDINATOR_URL` chọn bộ điều phối. Mặc định là bộ điều phối trên cùng máy. `network/up.sh` biên dịch guest và khởi động prover như một phần của mạng cục bộ; hãy làm theo [Chạy nó cục bộ](/vi/canton-zk-evm/run-it-locally.md) cho chuỗi bước đó.

Trình tạo mặc định là `prover/prove-one.sh` qua `CZE_PROVE_CMD`. Lệnh đó nhận một tệp đầu vào và thư mục đầu ra, và phải để lại `wrapped-proof.hex`. Kiểm tra cục bộ của nó `cargo-zisk` không cưỡng chế programVK và rootC đã ghim của chuỗi. Các sidecar của bên xác nhận cưỡng chế các ghim đó. Xem [thiết lập của trình tạo](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#settings).

## Tái tạo khóa của guest

Script biên dịch sử dụng một thư mục biên dịch cố định và từ chối một ELF vẫn còn chứa đường dẫn biên dịch. Chỉ chạy một lần biên dịch guest tại một thời điểm vì mỗi lần biên dịch sẽ làm trống thư mục dùng chung đó.

Vào ngày 2026-10-04, hai bản checkout mới được một người dùng trên một máy biên dịch tuần tự đã tạo ra cùng một ELF và programVK. Các lần biên dịch mất 133 s và 126 s. Để tái tạo bản biên dịch với tư cách người dùng khác hoặc trên máy khác, hãy kiểm tra rằng programVK thu được khớp với giá trị đã ghi. `network/up.sh` sẽ dừng nếu các ghim của bản biên dịch khác nhau. The [README của guest](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md#building) mô tả bản biên dịch và các giới hạn của nó.

## Đầu ra của bằng chứng

Định dạng dây là 1.344 byte: 768 byte bằng chứng PLONK, 32 byte programVK, 32 byte rootC và 512 byte giá trị công khai. `prove-one.sh` ghi dạng hex và JSON được tạo bởi `cargo-zisk-dev export-solidity-calldata`.


---

# 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/prover-host.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.
