> 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/rome-zk-evm/prover-host.md). # 프로버 호스트 ZisK 1.3.1-alpha로 Rome ZK EVM 배치를 증명하는 GPU 호스트의 크기를 정하고 준비하세요. 노드는 GPU 없이도 트랜잭션을 순서화하고 배치를 게시할 수 있습니다. Solana에서 어떤 루트도 최종 확정하려면 프로버가 필요합니다. v0.3.0에서는 프로버가 체인 제네시스를 위해 빌드된 게스트와 함께 ZisK 1.3.1-alpha를 실행합니다. 인박스 배치를 한 번에 하나씩 증명하고, 각 증명을 로컬에서 확인한 뒤 정산에 게시합니다. 위의 [전체 프로버-호스트 가이드](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) 에는 설정 및 복구 단계가 있습니다. 다음과 함께 사용하세요: [devnet 운영 가이드](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## 호스트 사양 산정 x86-64 Ubuntu 22.04 이상과 30GB가 넘는 메모리를 가진 NVIDIA GPU 1개를 사용하세요. 설정 스크립트는 약 32.2GB 이상인 GPU를 허용합니다. 최종 증명 단계는 약 30GB를 요구하므로 24GB 카드는 너무 작습니다. NVIDIA 드라이버는 최소 525.60.13이어야 합니다. 최소한 **128GB RAM** 및 **125GB의 여유 디스크 공간** 가 ZisK 설치 위치에 있어야 합니다. 1.3.1-alpha 증명 키 아카이브는 5.1GB이고 PLONK 키 아카이브는 21.9GB입니다. 설정이 상수 파일 생성을 완료한 후에는 두 키 디렉터리가 각각 21GiB와 26GiB였습니다. 첫 번째 증명은 캐시 파일을 추가합니다. CPU 호스트는 한 번의 증명 후 총 102.1GB를 사용했으며, GPU 캐시 증가량은 아직 측정되지 않았습니다. 1.3.1-alpha 증명 라이브러리는 약 300만 단계 배치에서 주 작업 버퍼에 24.7GB, 재귀에 5.6GB가 필요하다고 보고했습니다. 이 릴리스의 전체 프로세스 최대 사용량은 기록되지 않았습니다. devnet GPU 실행은 176GB RAM이 있는 호스트에서 수행되었으며, 최대 RAM 사용량도 기록되지 않았습니다. 128GB는 측정된 최대치가 아니라 크기 산정용 추정치로 사용하세요. ## 측정된 내용 거의 비어 있는 배치 하나는 약 **17초**가 걸렸으며, 여기에는 PLONK 래핑이 포함됩니다. 호스트는 **96GB RTX PRO 6000** 1개, 48개 CPU 코어, 176GB RAM을 사용했습니다. 약 95GB의 GPU 메모리가 사용 중으로 표시되었습니다. 이는 이 실행에서 실제로 사용된 값일 뿐, 모든 배치에 필요한 최소 GPU 메모리는 아닙니다. 더 큰 배치는 GPU에서 아직 시간 측정이 되지 않았습니다. Rome은 해당 GPU에서 거의 비어 있는 devnet 배치 116개를 약 35분 만에 처리했습니다. 이는 체인이 검증 키를 기다리는 동안 빈 블록을 생성한 경우에 중요합니다. 프로버는 더 최신 상태에 도달하기 전에 그것들을 순서대로 처리해야 합니다. ## 설정 스크립트를 실행하세요 NVIDIA 드라이버를 설치하고 필요하면 재부팅하세요. 저장소 루트에서 릴리스의 스크립트를 root로 실행합니다. 다음을 설정하세요. `ZISK_HOME` 를 ZisK와 해당 키가 위치할 디렉터리로 지정합니다. 롤업에서도 같은 값을 사용하세요. `.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 ``` 이 스크립트는 ZisK GPU 빌드, 증명 키와 PLONK 키, 필요한 시스템 라이브러리, 그리고 Docker의 NVIDIA 런타임을 설치합니다. 잠금 메모리 제한을 무제한으로 설정합니다. 이 제한이 셸에 적용되도록 로그아웃한 뒤 다시 로그인하세요. 그런 다음 GPU와 드라이버, 설치된 바이너리, 키, 메모리 제한, 컨테이너 런타임을 확인합니다. 설치 프로그램을 실행하기 전에 설치 프로그램의 SHA-256을 확인합니다. 두 키 아카이브를 압축 해제하기 전에 둘 다 확인하고, 설치된 `cargo-zisk` 및 `cargo-zisk-dev` GPU 바이너리를 스크립트가 실행하기 전에 확인합니다. 집계와 PLONK 증명에 필요한 상수 파일을 생성합니다. 실행이 실패하면 스크립트를 다시 실행하세요. 설치된 키가 이미 고정된 매니페스트와 일치하면 키 다운로드를 건너뜁니다. 이 스크립트는 ZisK 설치의 모든 부분을 확인하지는 않습니다. 설치 프로그램은 바이너리 번들을 가져오고, 스크립트가 설치된 두 GPU 바이너리를 확인하기 전에 해당 툴체인 설치 프로그램을 실행합니다. 그 번들에 있는 다른 실행 파일과 소스 파일은 이 스크립트에서 해시 확인되지 않습니다. 전체 가이드에는 이 제한이 명시되어 있으며, 각 다운로드를 개별적으로 확인하는 명령이 포함되어 있습니다. ## 체인에 연결하세요 프로버에는 일치하는 게스트 ELF, 해당 검증 메타데이터, 그리고 동일한 1.3.1-alpha 증명 키가 필요합니다. 롤업 설정에서 `PROVER=on` 과 게스트 및 ZisK 설정을 지정한 다음 `./rollup init` 및 `./rollup up`을 실행하세요. 첫 실행은 v0.3.0 소스에서 프로버 이미지를 빌드합니다. 노드 이미지 자체에는 프로버가 포함되어 있지 않습니다. 시작하기 전에 프로버는 설치된 증명 키를 고정된 SHA-256 매니페스트와 비교합니다. 그 검사는 파일 이름과 내용을 포함합니다. 생성된 constant-tree 및 GPU 상수 파일은 호스트마다 다르므로 제외됩니다. 불일치가 발생하면 프로버는 `KeysShaMismatch`로 중단합니다. 불일치하는 설치를 시작하기 위해 매니페스트를 변경하지 마세요. 체인의 게스트와 등록된 키에 맞는 릴리스를 설치하세요. 실행하세요 `./rollup check` 시작 후. 프로버 서비스, 활성 검증 키, 정산 및 프로버 지연을 확인합니다. [모니터링 가이드](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) 에는 로컬 메트릭과 유용한 경보 조건이 나열되어 있습니다. --- # 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/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.