> 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/prover-host.md). # Máy chủ prover Định cỡ và chuẩn bị máy chủ GPU dùng để chứng minh các batch Rome ZK EVM với ZisK 1.3.1-alpha. Nút có thể sắp xếp thứ tự giao dịch và đăng các lô mà không cần GPU. Nó cần một prover để làm cho bất kỳ root nào được chốt cuối cùng trên Solana. Trong v0.3.0, prover chạy ZisK 1.3.1-alpha với guest được build cho genesis của chuỗi bạn. Nó chứng minh từng lô inbox một, kiểm tra từng bằng chứng cục bộ, rồi đăng nó lên settlement. Các [hướng dẫn đầy đủ về prover-host](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) có các bước thiết lập và khôi phục. Hãy dùng nó cùng với [runbook devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## Chọn kích cỡ host Dùng Ubuntu 22.04 x86-64 hoặc mới hơn và một GPU NVIDIA với bộ nhớ lớn hơn 30 GB. Script thiết lập chấp nhận GPU có khoảng 32,2 GB trở lên. Bước chứng minh cuối cùng cần khoảng 30 GB, nên card 24 GB là quá nhỏ. Driver NVIDIA phải ít nhất là 525.60.13. Cho phép ít nhất **128 GB RAM** và **125 GB dung lượng đĩa trống** tại vị trí cài đặt ZisK. Kho lưu trữ proving-key 1.3.1-alpha có dung lượng 5,1 GB và kho lưu trữ khóa PLONK có dung lượng 21,9 GB. Sau khi phần thiết lập tạo xong các tệp hằng số, hai thư mục khóa lần lượt có dung lượng 21 GiB và 26 GiB. Bằng chứng đầu tiên sẽ thêm các tệp cache. Một host CPU có tổng dung lượng 102,1 GB sau một bằng chứng, và mức tăng cache của GPU chưa được đo. Thư viện chứng minh 1.3.1-alpha báo cáo 24,7 GB cho bộ đệm làm việc chính và 5,6 GB cho đệ quy trên một lô khoảng 3 triệu bước. Mức đỉnh của toàn bộ tiến trình trên bản phát hành này chưa được ghi lại. Lần chạy GPU devnet dùng một host có 176 GB RAM; mức sử dụng RAM đỉnh của nó cũng chưa được ghi lại. Hãy dùng 128 GB như ước tính kích thước, không phải mức đỉnh đo được. ## Những gì đã được đo Một lô gần như rỗng mất khoảng **17 giây**, bao gồm cả phần bọc PLONK, trên một host với một **RTX PRO 6000 96 GB**, 48 lõi CPU và 176 GB RAM. Khoảng 95 GB bộ nhớ GPU hiển thị đang được dùng. Đó là mức mà lần chạy này sử dụng, không phải bộ nhớ GPU tối thiểu cho mọi lô. Các lô lớn hơn chưa được đo thời gian trên GPU. Rome đã xử lý xong 116 lô devnet gần như rỗng trong khoảng 35 phút trên GPU đó. Điều đó quan trọng khi một chuỗi đã tạo ra các block rỗng trong lúc chờ verification key của nó: prover phải xử lý chúng theo đúng thứ tự trước khi có thể đạt tới trạng thái mới hơn. ## Chạy script thiết lập Cài driver NVIDIA và khởi động lại nếu cần. Từ thư mục gốc của repository, chạy script của bản phát hành với quyền root. Đặt `ZISK_HOME` thành thư mục nơi ZisK và các key của nó sẽ nằm. Hãy dùng cùng giá trị đó trong rollup của bạn `.env`: ```sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh --check ``` Script này cài bản build GPU của ZisK, các key chứng minh và PLONK của nó, các thư viện hệ thống cần thiết, và NVIDIA runtime của Docker. Nó đặt giới hạn bộ nhớ khóa thành không giới hạn. Hãy đăng xuất rồi đăng nhập lại để giới hạn đó áp dụng cho shell của bạn. Sau đó nó kiểm tra GPU và driver, các binary đã cài, keys, giới hạn bộ nhớ và container runtime. Trước khi chạy trình cài đặt, nó kiểm tra SHA-256 của trình cài đặt. Nó kiểm tra cả hai kho key trước khi giải nén bất kỳ kho nào, và kiểm tra các `cargo-zisk` và `cargo-zisk-dev` binary GPU đã cài trước khi script chạy chúng. Nó tạo các tệp hằng số cần cho aggregation và chứng minh PLONK. Nếu một lần chạy thất bại, hãy chạy lại script. Nó bỏ qua việc tải key khi các key đã cài khớp với manifest đã ghim. Script không kiểm tra mọi phần của bản cài đặt ZisK. Trình cài đặt tải một gói binary và chạy trình cài toolchain của nó trước khi script kiểm tra hai binary GPU đã cài. Các executable và tệp nguồn khác trong gói đó không được script này kiểm tra hash. Hướng dẫn đầy đủ nêu rõ giới hạn này và có các lệnh để kiểm tra từng bản tải xuống riêng biệt. ## Kết nối nó với chuỗi của bạn Prover cần ELF guest khớp, metadata xác minh của nó, và cùng bộ proving keys 1.3.1-alpha. Hãy đặt `PROVER=on` và các thiết lập guest cùng ZisK trong cấu hình rollup, rồi chạy `./rollup init` và `./rollup up`. Lần chạy đầu tiên sẽ build image prover từ source v0.3.0. Chỉ image của node thôi thì không chứa prover. Trước mỗi lần khởi động, prover sẽ kiểm tra các proving keys đã cài so với manifest SHA-256 đã ghim. Việc kiểm tra đó bao gồm tên tệp và nội dung. Các tệp constant-tree và constant GPU được tạo ra bị loại trừ vì chúng khác nhau theo host. Bất kỳ sai lệch nào cũng sẽ làm prover dừng với `KeysShaMismatch`. Đừng sửa manifest chỉ để làm cho một bản cài đặt không khớp có thể khởi động; hãy cài bản phát hành khớp với guest của chuỗi và key đã đăng ký. Chạy `./rollup check` sau khi khởi động. Nó kiểm tra dịch vụ prover, verification key đang hoạt động, và độ trễ của settlement và prover. [hướng dẫn giám sát](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) liệt kê các chỉ số cục bộ và các điều kiện cảnh báo hữu ích. --- # 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/prover-host.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.