> 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/run-it-locally.md).

# Execute-o localmente

Execute as verificações, o ensaio sem GPU e a demo local do Ostia em uma GPU.

Os scripts fornecidos executam uma rede de teste local. O Canton mantém seu estado na memória, então cada reinicialização descarta esse estado e cria uma nova rede. A demonstração com GPU prova blocos. O ensaio usa uma prova substituta e não precisa de GPU.

Esta página descreve o commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Leia o completo [guia da rede](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/network/README.md) e [guia de demonstração](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md). Execute os comandos abaixo a partir da `canton-zk-evm` raiz do repositório.

## O que você precisa

| Trabalho                       | Requisitos                                                                                                                      |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| Verificações do repositório    | Docker, `bash`, `curl`, `jq`, `openssl` e Python 3. Os testes em Rust usam `rust-toolchain.toml`.                               |
| testes de integração do Canton | Linux x86-64, Java 21 e acesso à rede.                                                                                          |
| Ensaio da demonstração         | Linux x86-64, Docker, Java 21, Rust e Python 3.12 ou mais recente.                                                              |
| Testes do explorador           | Node 22.18 ou mais recente.                                                                                                     |
| Rede com GPU e demonstração    | Linux x86-64, uma GPU NVIDIA com o driver instalado, Docker, Rust, Python 3.12 ou mais recente, `jq`, `curl`, `openssl` e ZisK. |

Os [README do repositório](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/README.md#running-the-tests) lista os pré-requisitos dos testes. O instalador da GPU usa `sudo` e `apt` no Debian ou Ubuntu e precisa de 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 buscador de ferramentas da rede instala Java 21 se estiver ausente. Veja [Host do prover](/pt-br/canton-zk-evm/prover-host.md) para o hardware testado; o mínimo de memória da GPU não foi estabelecido.

## Execute os testes

Comece com as verificações rápidas de [CONTRIBUTING.md](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/CONTRIBUTING.md#building-and-testing):

```sh
tests/static.sh                  # os pins, o genesis e as linhas de licença concordam
tests/refuses_missing_flag.sh    # a inicialização do reth recusa uma flag ausente ou incorreta
tests/fixtures.sh                # a prova gravada é consistente
gateway/build.sh --check         # o código do gateway incluído no repositório é o que Gateway.sol compila para (Docker)
```

O README do repositório também fornece estas verificações. Elas não precisam de GPU:

```sh
tests/udp_control.sh             # a verificação de UDP falha em um contêiner com um ouvinte UDP (sem reth)
tests/discovery.sh               # inicia o reth fixado, verifica que ele não tem pares, para-o
tests/network_static.sh          # reth apenas por meio de launch.sh, a configuração do Canton, o resultado de smoke gravado
tests/network_checks.sh          # a verificação do pin do compilador, o id do DAR, a parada em outro programaVK (sem GPU)
tests/canton_network.sh          # o Canton fixado, o pacote Daml real e um Advance (Linux x86-64, Java 21, Python 3; sem GPU)
gateway/tests/run.sh             # o gateway em um reth real, iniciado com a descoberta de pares desativada (Docker, curl, jq, Python 3 com os pacotes em demo/requirements.txt)
tests/guest-repro.sh             # a compilação do guest é executada em uma pasta fixa, então a pasta de origem não altera o ELF (substitutos para as ferramentas ZisK; a mesma verificação no ZisK real passou em 2026-10-04, veja guest/README.md)
tests/demo_static.sh             # os pins da demonstração, o interruptor de adulteração e a substituição do genesis, e seus resultados gravados (sem GPU)
tests/demo_explorer_static.sh    # as imagens do explorador estão fixadas, e o que é fornecido ao seu contêiner (sem Docker)
(cd explorer && npm ci && npm test)  # os testes do explorador, contra fakes (Node 22.18+; a CI usa EXPLORER_NODE_IMAGE em PINS)
(cd guest/rules && cargo test)   # as regras da cadeia e seu hash (precisa de Rust)
```

## Ensaio sem GPU

```sh
tests/demo_rehearsal.sh          # a demonstração e o explorador com uma prova substituta (Linux x86-64, Docker, Java 21, Rust, Python 3.12+; sem GPU)
```

Isso executa o reth real, Canton, pacote Daml, padrão de token e builder. O sidecar verifica as pernas do gateway contra provas de armazenamento, enquanto um substituto responde à `verificar` chamada. O ensaio não prova um bloco nem verifica uma prova real de conhecimento zero.

Ele também verifica o explorador e o faucet. A verificação Verify do explorador deve rejeitar a prova substituta. O [README da demonstração](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#the-rehearsal) descreve a cobertura do ensaio.

## Inicie a rede local com uma GPU

Instale o ZisK com `prover/install.sh` antes de iniciar a rede. Sempre inicie o reth pelo inicializador fornecido; `network/up.sh` o usa.

```sh
network/up.sh       # ferramentas, build do guest, reth, sidecars, prover, Canton, a cadeia
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) network/smoke.sh    # um bloco vazio, provado e confirmado
network/down.sh
```

`up.sh` compila o guest e recusa uma chave de programa, raiz ZisK ou hash de regras que seja diferente dos valores gravados. A rede tem um sincronizador e três participantes. Os participantes operador e confirmador executam cada um um sidecar. O participante chamado users hospeda as partes de teste e o leitor.

O teste smoke confirma um bloco vazio, verifica a cabeça da cadeia e o registro de blocos do leitor, e verifica que o reth o marcou como final. O estado e os logs vão para `state/`, ou `CZE_STATE_DIR` quando definido.

## Execute os cinco casos da demonstração em uma GPU

Use uma nova rede local para a demonstração:

```sh
demo/prepare.sh
CZE_GENESIS_FILE=$PWD/state/demo/genesis.json network/up.sh
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) network/smoke.sh      # opcional: um bloco vazio primeiro
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) demo/run.sh
network/down.sh
```

O script de preparação cria chaves de teste e um genesis financiado para a execução. A demonstração executa seu bloco de configuração, depósito, pagamento, saque, recusa de alocação e recusa de prova adulterada. O script para se uma verificação falhar e escreve seus resultados em `demo/results/`.

Para uma exportação do código-fonte sem `.git`, defina `CZE_SOURCE_COMMIT` para o hash completo do commit usado na exportação. Para incluir o faucet, o genesis financiado dele precisa ser preparado antes de a rede iniciar; veja [Explorador](/pt-br/canton-zk-evm/explorer.md) e o guia completo da demonstração.


---

# 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/run-it-locally.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.