> 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/ko/canton-zk-evm/prover-host.md).

# 프로버 호스트

증명기의 호스트 요구사항, 지속형 워커, 그리고 고정된 게스트 빌드.

프로버는 GPU 워커 1개와 함께 ZisK를 실행합니다. 코디네이터와 워커는 요청 사이에도 계속 실행 상태를 유지하며, PLONK 키는 이미 로드되어 있습니다. 각 블록마다 빌더는 입력을 보내고 래핑된 증명을 받습니다.

이 페이지는 커밋에 대해 설명합니다 `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. 전체 내용을 읽어보세요 [프로버 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/prover/README.md) 및 [측정치](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md).

## 호스트 요구 사항

설치 프로그램은 다음 환경의 Linux x86-64를 대상으로 합니다: `apt`, `sudo`, 설치된 NVIDIA 드라이버와 약 100GB의 여유 디스크 공간이 있는 환경입니다. 시스템 패키지를 설치하고 메모리 잠금 한도를 변경합니다.

2026-10-03 벤치마크는 GPU 메모리 96GB의 NVIDIA RTX PRO 6000 Blackwell Server Edition 1개, AMD EPYC 9B45의 48 vCPU, 그리고 호스트 RAM 176GiB를 사용했습니다. Ubuntu 22.04.5와 드라이버 580.178.04에서 실행되었습니다. 이러한 사양은 테스트된 머신을 설명할 뿐이며, 프로버를 실행하는 데 필요한 최소 하드웨어를 규정하지는 않습니다.

벤치마크는 에뮬레이터 공유 메모리 22.9GiB를 기록했습니다. PLONK 래핑만으로도 GPU 요구량이 30,054,767,337바이트, 즉 약 28.0GiB로 보고되었습니다. GPU 메모리 사용량의 피크는 93.2GiB였지만, 프로버는 카드에 큰 버퍼를 할당합니다. 그 피크는 버퍼 할당을 반영할 뿐이며 전체 프로버가 최소한으로 얼마나 많은 GPU 메모리를 필요로 하는지는 보여주지 않습니다. 다음을 참조하세요 [측정](/ko/canton-zk-evm/measurements.md) 각 수치의 범위는 다음을 참조하세요.

## 빌드 및 실행

스크립트는 다음에 있는 버전을 사용합니다: [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). 프로버는 ZisK 1.3.1-alpha, Node 20.20.2 및 snarkjs 0.7.6을 사용합니다. 탐색기의 Node 버전은 별도입니다.

| 스크립트                    | 하는 일                                                               |
| ----------------------- | ------------------------------------------------------------------ |
| `prover/install.sh`     | 설치 프로그램의 고정 체크섬을 확인한 다음, GPU 빌드, 증명 키, PLONK 설정을 설치하세요.            |
| `prover/build-guest.sh` | 게스트 ELF를 빌드하고 그 SHA-256, programVK, rootC 및 rules 해시를 출력합니다.       |
| `prover/start.sh`       | PLONK 키가 로드된 상태로 코디네이터와 GPU 워커 1개를 시작합니다.                          |
| `prover/make-input.sh`  | 저장된 블록, 실행 증인, 제네시스를 프로버 입력으로 변환합니다.                               |
| `prover/prove-one.sh`   | 하나의 입력을 증명하고, 다음으로 증명을 검증합니다: `cargo-zisk`, 그리고 래핑된 증명을 16진수로 씁니다. |

`ZISK_COORDINATOR_URL` 코디네이터를 선택합니다. 기본값은 동일한 머신의 코디네이터입니다. `network/up.sh` 게스트를 빌드하고 로컬 네트워크의 일부로 프로버를 시작합니다. 다음을 따르세요: [로컬에서 실행](/ko/canton-zk-evm/run-it-locally.md) 그 순서를 위해.

빌더의 기본값은 다음입니다: `prover/prove-one.sh` 을 통해 `CZE_PROVE_CMD`. 해당 명령은 입력 파일과 출력 폴더를 받고 다음을 남겨야 합니다: `wrapped-proof.hex`. 그 로컬 `cargo-zisk` 검사는 체인의 고정된 programVK와 rootC를 강제하지 않습니다. confirmer의 사이드카드가 해당 고정을 강제합니다. 다음을 참조하세요: [빌더 설정](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#settings).

## 게스트 키 재현

빌드 스크립트는 고정된 빌드 폴더 하나를 사용하며, 아직 빌드 경로를 포함하고 있는 ELF는 거부합니다. 각 빌드는 이 공유 폴더를 비우므로 한 번에 하나의 게스트 빌드만 실행하세요.

2026-10-04에 한 사용자가 한 머신에서 순차적으로 빌드한 두 개의 새 체크아웃은 동일한 ELF와 programVK를 생성했습니다. 빌드는 각각 133초와 126초가 걸렸습니다. 다른 사용자로서 또는 다른 머신에서 빌드를 재현하려면, 생성된 programVK가 기록된 값과 일치하는지 확인하세요. `network/up.sh` 빌드의 고정값이 다르면 중단됩니다.  [게스트 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md#building) 빌드와 그 제한 사항을 설명합니다.

## 증명 출력

와이어 형식은 1,344바이트입니다: 768바이트의 PLONK 증명, 32바이트의 programVK, 32바이트의 rootC, 그리고 512바이트의 공개 값입니다. `prover/prove-one.sh` 16진수 형식과 다음이 생성한 JSON을 씁니다: `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/ko/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.