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

# Host do prover

Os requisitos de host do provador, o worker persistente e a build fixada do guest.

O prover executa o ZisK com um worker de GPU. O coordenador e o worker permanecem em execução entre as requisições, com a chave PLONK já carregada. Para cada bloco, o builder envia a entrada e recebe uma prova encapsulada.

Esta página descreve o commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Leia o completo [README do prover](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/prover/README.md) e [medições](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md).

## Requisitos do host

O instalador é voltado para Linux x86-64 com `apt`, `sudo`, um driver NVIDIA instalado e cerca de 100 GB de espaço livre em disco. Ele instala pacotes do sistema e altera os limites de bloqueio de memória.

O benchmark de 2026-10-03 usou uma NVIDIA RTX PRO 6000 Blackwell Server Edition com 96 GB de memória de GPU, 48 vCPUs em um AMD EPYC 9B45 e 176 GiB de RAM do host. Ele rodou no Ubuntu 22.04.5 com driver 580.178.04. Essas especificações descrevem a máquina testada; elas não estabelecem o hardware mínimo necessário para executar o prover.

O benchmark registrou 22,9 GiB de memória compartilhada do emulador. O wrap do PLONK sozinho relatou um requisito de GPU de 30.054.767.337 bytes, cerca de 28,0 GiB. O uso máximo de memória da GPU foi de 93,2 GiB, mas o prover aloca um buffer grande para a placa. Esse pico reflete a alocação do buffer e não mostra quanta memória de GPU o prover inteiro precisa no mínimo. Veja [Medições](/pt-br/canton-zk-evm/measurements.md) o escopo de cada número.

## Compilar e executar

Os scripts usam as versões em [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). O prover usa ZisK 1.3.1-alpha, Node 20.20.2 e snarkjs 0.7.6. A versão do Node do explorer é separada.

| Script                  | O que faz                                                                                                                                      |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `prover/install.sh`     | Verifique a soma de verificação fixada do instalador e, em seguida, instale a compilação para GPU, a chave de prova e a configuração do PLONK. |
| `prover/build-guest.sh` | Compila o ELF do guest e imprime seu SHA-256, programVK, rootC e hash de rules.                                                                |
| `prover/start.sh`       | Inicia o coordenador e um worker de GPU com a chave PLONK carregada.                                                                           |
| `prover/make-input.sh`  | Transforma um bloco salvo, uma witness de execução e o genesis em entrada do prover.                                                           |
| `prover/prove-one.sh`   | Prova uma entrada, verifica a prova com `cargo-zisk`, e grava a prova encapsulada em hexadecimal.                                              |

`ZISK_COORDINATOR_URL` seleciona o coordenador. O padrão é o coordenador na mesma máquina. `network/up.sh` compila o guest e inicia o prover como parte da rede local; siga [Execute-o localmente](/pt-br/canton-zk-evm/run-it-locally.md) para essa sequência.

O builder usa como padrão `prover/prove-one.sh` por meio de `CZE_PROVE_CMD`. Esse comando recebe um arquivo de entrada e uma pasta de saída e deve deixar `wrapped-proof.hex`. Sua `cargo-zisk` verificação local não impõe os pins de programVK e rootC fixados pela cadeia. Os sidecars dos confirmers impõem esses pins. Veja as [configurações do builder](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#settings).

## Reproduza a chave do guest

O script de build usa uma pasta de build fixa e recusa um ELF que ainda contenha um caminho de build. Execute apenas um build de guest por vez, porque cada build esvazia essa pasta compartilhada.

Em 2026-10-04, dois checkouts novos compilados sequencialmente por um usuário em uma máquina produziram o mesmo ELF e o mesmo programVK. As compilações levaram 133 s e 126 s. Para reproduzir a compilação como outro usuário ou em outra máquina, verifique se o programVK resultante corresponde ao valor registrado. `network/up.sh` para se os pins da compilação diferirem. O [README do guest](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md#building) descreve a compilação e seus limites.

## Saída da prova

O formato de wire tem 1.344 bytes: 768 bytes de prova PLONK, 32 bytes de programVK, 32 bytes de rootC e 512 bytes de valores públicos. `prove-one.sh` grava a forma hexadecimal e o JSON produzido por `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/pt-br/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.