> 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/pt-br/rome-zk-evm/prover-host.md). # Host do prover Dimensione e prepare o host com GPU que prova batches Rome ZK EVM com ZisK 1.3.1-alpha. O nó pode sequenciar transações e publicar lotes sem uma GPU. Ele precisa de um provador para tornar qualquer root final na Solana. Na v0.3.0, o provador executa ZisK 1.3.1-alpha com o guest compilado para o genesis da sua cadeia. Ele prova lotes da inbox um de cada vez, verifica cada prova localmente e então a publica para liquidação. Os [guia completo do provador-host](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) tem as etapas de configuração e recuperação. Use-o com o [runbook da devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## Dimensione o host Use Ubuntu x86-64 22.04 ou posterior e uma GPU NVIDIA com mais de 30 GB de memória. O script de configuração aceita uma GPU com cerca de 32,2 GB ou mais. A etapa final de prova pede cerca de 30 GB, então uma placa de 24 GB é pequena demais. O driver NVIDIA deve ser pelo menos 525.60.13. Reserve pelo menos **128 GB de RAM** e **125 GB livres em disco** no local de instalação do ZisK. O arquivo compactado da chave de prova 1.3.1-alpha tem 5,1 GB e o arquivo compactado da chave PLONK tem 21,9 GB. Depois que a configuração gerou seus arquivos constantes, os dois diretórios de chaves mediram 21 GiB e 26 GiB. A primeira prova adiciona arquivos de cache. Um host com CPU mediu 102,1 GB no total após uma prova, e o crescimento do cache da GPU ainda não foi medido. A biblioteca de prova 1.3.1-alpha informou 24,7 GB para seu buffer principal de trabalho e 5,6 GB para recursão em um lote de cerca de 3 milhões de etapas. O pico de todo o processo nesta versão não foi registrado. A execução na GPU da devnet usou um host com 176 GB de RAM; o uso máximo de RAM também não foi registrado. Use 128 GB como estimativa de dimensionamento, não como pico medido. ## O que foi medido Um lote quase vazio levou cerca de **17 segundos**, incluindo o envoltório PLONK, em um host com uma **RTX PRO 6000 de 96 GB**, 48 núcleos de CPU e 176 GB de RAM. Cerca de 95 GB de memória da GPU apareciam em uso. Isso é o que essa execução consumiu, não o mínimo de memória da GPU para todo lote. Lotes maiores ainda não foram cronometrados em uma GPU. Rome processou 116 lotes da devnet quase vazios em cerca de 35 minutos nessa GPU. Isso importa quando uma cadeia produziu blocos vazios enquanto aguardava sua chave de verificação: o provador precisa processá-los em ordem antes de alcançar um estado mais recente. ## Execute o script de configuração Instale o driver NVIDIA e reinicie, se necessário. A partir da raiz do repositório, execute o script da release como root. Defina `ZISK_HOME` para o diretório onde o ZisK e suas chaves ficarão. Use o mesmo valor em seu rollup `.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 ``` O script instala a versão do ZisK para GPU, suas chaves de prova e PLONK, as bibliotecas de sistema de que ele precisa e o runtime NVIDIA do Docker. Ele define o limite de memória bloqueada como ilimitado. Saia e entre novamente para que esse limite se aplique ao seu shell. Em seguida, ele verifica a GPU e o driver, os binários instalados, as chaves, o limite de memória e o runtime do contêiner. Antes de executar o instalador, ele verifica o SHA-256 do instalador. Ele verifica ambos os arquivos compactados das chaves antes de descompactar qualquer um deles e verifica o instalado `cargo-zisk` e `cargo-zisk-dev` binários de GPU antes de o script executá-los. Ele gera os arquivos constantes necessários para agregação e prova PLONK. Se uma execução falhar, execute o script novamente. Ele pula o download das chaves quando as chaves instaladas já correspondem ao manifesto fixado. O script não verifica todas as partes da instalação do ZisK. O instalador baixa um pacote binário e executa seu instalador da cadeia de ferramentas antes de o script verificar os dois binários de GPU instalados. Outros executáveis e arquivos-fonte nesse pacote não têm hash verificado por este script. O guia completo explica essa limitação e traz os comandos para verificar cada download separadamente. ## Conecte-o à sua cadeia O provador precisa do ELF guest correspondente, de seus metadados de verificação e das mesmas chaves de prova 1.3.1-alpha. Defina `PROVER=on` e as configurações do guest e do ZisK na configuração do rollup, então execute `./rollup init` e `./rollup up`. A primeira execução compila a imagem do provador a partir do código-fonte v0.3.0. A imagem do nó sozinha não contém o provador. Antes de cada inicialização, o provador verifica as chaves de prova instaladas em relação ao manifesto SHA-256 fixado. Essa verificação cobre nomes e conteúdos dos arquivos. Os arquivos constant-tree e constant da GPU gerados são excluídos porque variam de host para host. Uma incompatibilidade interrompe o provador com `KeysShaMismatch`. Não altere o manifesto só para fazer uma instalação incompatível iniciar; instale a release que corresponda ao guest da cadeia e à chave registrada. Execute `./rollup check` após a inicialização. Ele verifica o serviço do provador, a chave de verificação ativa e o atraso da liquidação e do provador. O [guia de monitoramento](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) lista as métricas locais e condições de alerta úteis. --- # 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/pt-br/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.