> 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/measurements.md).

# Medições

Medições registradas de prova e liquidação com suas datas, hardware e limites.

O benchmark do provador e as execuções no Ostia mediram guests e cargas de trabalho diferentes. O benchmark usou o guest upstream reth sem modificações. As execuções no Ostia usaram o guest deste repositório com sua verificação de chain-rules e o gateway.

Esta página descreve o commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Leia o completo [relatório de métricas](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md) e [resultados da demo](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results).

## Hardware

Ambos os conjuntos usaram uma GPU NVIDIA RTX PRO 6000 Blackwell Server Edition. Para a demo do Ostia, só a GPU e o driver foram registrados.

| Item                        | Benchmark do provador, 2026-10-03                                                   | Execuções no Ostia, 2026-10-05 |
| --------------------------- | ----------------------------------------------------------------------------------- | ------------------------------ |
| CPU                         | AMD EPYC 9B45, 48 vCPUs; um socket, dois threads por núcleo                         | Não registrado                 |
| RAM do host                 | 176 GiB conforme reportado pelo host                                                | Não registrado                 |
| Memória da GPU              | 97,887 MiB, descritos como 96 GB; PCIe gen 5 x16                                    | Capacidade não registrada      |
| Driver                      | 580.178.04                                                                          | 580.178.04                     |
| CUDA                        | 13.0 no nível do driver; binários pré-compilados da GPU, sem CUDA Toolkit instalado | Não registrado                 |
| Sistema operacional e disco | Ubuntu 22.04.5, disco de boot de 500 GB                                             | Não registrado                 |
| Node e snarkjs              | 20.18.0 e 0.7.6                                                                     | Não registrado                 |

## Versões fixadas

Estas são as versões do repositório, conforme listadas no relatório de métricas e [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). A versão do Node do host do benchmark acima difere da versão fixada do provador.

| Componente                            | Versão                                                         |
| ------------------------------------- | -------------------------------------------------------------- |
| ZisK                                  | 1.3.1-alpha                                                    |
| Fonte do guest upstream               | 0.13.1                                                         |
| reth                                  | 2.5.2                                                          |
| Canton                                | 3.6.0-snapshot.20260930.20337.0.ve610bc8f                      |
| Daml SDK para a chamada externa       | 3.5.13-snapshot.20261001.145.0.v852bdd82                       |
| Compilador Daml                       | 3.6.0-snapshot.20260915.14804.0.v53478765, visando Daml-LF 2.4 |
| Daml SDK para testes Script           | 3.5.12, visando Daml-LF 2.1                                    |
| Java                                  | 21                                                             |
| Rust                                  | 1.94.1                                                         |
| Python do builder e da demo           | 3.12 ou mais recente                                           |
| Node do provador e snarkjs            | 20.20.2 e 0.7.6                                                |
| Explorer Node                         | 22.18 ou mais recente localmente; 24 no contêiner e no CI      |
| Compilador Solidity do token de teste | 0.8.28                                                         |

## Benchmark do provador: 2026-10-03

A tabela mostra tempos medianos em segundos de três execuções com aquecimento para cada tamanho de bloco. Cada bloco continha transferências simples. Cada prova passou `cargo-zisk verify`. Os logs brutos do benchmark não estão no repositório.

| Bloco                          | Prova sem wrap, processo novo | Wrap sozinho, processo novo | Prova com wrap, processo novo | Processo novo completo | Provador em execução: entrada para a prova com wrap | Provador em execução: entrada para a prova verificada |
| ------------------------------ | ----------------------------- | --------------------------- | ----------------------------- | ---------------------- | --------------------------------------------------- | ----------------------------------------------------- |
| 1 transferência, 21 kgas       | 4.6                           | 2.4                         | 7.4                           | 21.1                   | 6.7                                                 | 7.0                                                   |
| 1.000 transferências, 21 Mgas  | 6.9                           | 2.4                         | 9.6                           | 24.5                   | 9.0                                                 | 9.3                                                   |
| 5.000 transferências, 105 Mgas | 17.9                          | 2.4                         | 20.8                          | 34.9                   | 21.2                                                | 21.5                                                  |

O provador em execução manteve o coordenador, o worker e as chaves carregados. Os totais do processo novo incluem iniciar e encerrar o provador. Os tempos de entrada para prova começam com um arquivo de witness já existente; eles não medem a construção do witness. O caso de 105 Mgas foi um benchmark do guest upstream, não um bloco do Ostia. O limite de gas do bloco fixado do Ostia é 30.000.000.

| Medição da prova            | PLONK com wrap      | STARK sem wrap          |
| --------------------------- | ------------------- | ----------------------- |
| Tamanho do arquivo de prova | 2,942 a 2,944 bytes | 415,232 a 415,234 bytes |
| `cargo-zisk verify` tempo   | 0.29 a 0.30 s       | 0.03 s                  |
| Tamanho do wire             | 1.344 bytes         | Não medido              |

Verificar a prova com wrap inclui iniciar o Node para executar o snarkjs. Isso não é uma medição do verificador nativo do sidecar. O formato wire de 1.344 bytes contém 768 bytes de prova, 32 bytes de chave do programa, 32 bytes da raiz de recursão e 512 bytes de valores públicos.

## Inicialização e memória

Essas medições são do mesmo benchmark de 2026-10-03 com ZisK 1.3.1-alpha.

| Medição                                                                                                                             | Resultado                                                          |
| ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Primeira execução com 1 transferência após excluir o cache do ZisK e limpar o cache de páginas, com a chave de prova ainda no disco | 123 s de tempo total; o trabalho da prova levou 14,5 s             |
| Inicialização do provador em execução com o cache compilado do guest já presente                                                    | Chaves carregadas em 7,0 s, depois 9,5 s para registrar o programa |
| Primeira solicitação de prova após essa inicialização                                                                               | 6,56 s                                                             |
| Memória máxima da GPU reportada por `nvidia-smi`                                                                                    | 93,2 GiB                                                           |
| Aumento da RAM do host durante uma prova em processo novo                                                                           | 27 a 29 GiB, mais 22,9 GiB de memória compartilhada                |
| Aumento da RAM do host enquanto o provador em execução atendia requisições                                                          | 3 GiB, mais 22,9 GiB de memória compartilhada                      |
| Memória de GPU reportada apenas para o wrap PLONK                                                                                   | 30,054,767,337 bytes, cerca de 28,0 GiB                            |

O provador dimensiona um grande buffer de GPU para a placa. O uso máximo foi aproximadamente o mesmo para os menores e maiores blocos do benchmark. Isso não estabelece a memória mínima de GPU necessária para o provador completo.

## Demo do Ostia: 2026-10-05

Cada caso foi executado uma vez na rede Canton local, com o provador já em execução, a partir do commit `6b445073163832e9023850f53678617d90dfc808`. Estes são resultados individuais de teste. O [pasta de resultados](https://github.com/rome-protocol/canton-zk-evm/tree/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/results) contém os registros. [Visão geral](/pt-br/canton-zk-evm/canton-zk-evm.md#what-the-demo-showed) descreve os cinco resultados.

| Caso                | Bloco e gas usados                                                                      | Prova                                                                                  | Arquivo de prova concluído até a saída do builder | Execução completa do builder          |
| ------------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------- |
| Smoke               | Bloco 1, vazio; 0 gas                                                                   | 6,31 s                                                                                 | 0.49 s                                            | 155.20 s                              |
| Configuração        | Bloco 2, duas transações; gas não registrado                                            | 6.71 s                                                                                 | Não registrado                                    | 8.00 s                                |
| Depósito            | Bloco 3, uma transação; 122,308 gas                                                     | 6,72 s                                                                                 | 0.66 s                                            | 8.14 s                                |
| Pagamento           | Bloco 4, três transações; 185,307 gas                                                   | 6,72 s                                                                                 | 0.42 s                                            | 7.87 s                                |
| Saque               | Bloco 5, uma transação; 90,345 gas                                                      | 6,72 s                                                                                 | 0.58 s                                            | 8.02 s                                |
| Alocação recuperada | Bloco 6 rejeitado, depois reconstruído com uma transação e sem legs; gas não registrado | 6.75 s para a construção rejeitada; a segunda prova não foi cronometrada separadamente | Submissão rejeitada não cronometrada              | 8.09 s rejeitados; 8.04 s confirmados |
| Prova adulterada    | Bloco 7 rejeitado; gas não registrado                                                   | 6,74 s antes da adulteração                                                            | Submissão rejeitada não cronometrada              | 7.57 s                                |

Cada prova tinha 1.344 bytes. O intervalo do arquivo de prova finalizado até a saída do builder inclui a busca das provas de conta e de armazenamento do gateway, `Avançar`, commit em ambos os participantes confirmadores e o reth marcando o bloco como final. É mais longo do que o commit do Canton sozinho. O mapeamento das legs para os contratos do Canton acontece antes da prova e fica fora desse intervalo.

A execução completa do teste smoke inclui a preparação do witness e da entrada e a configuração inicial do programa guest pelo provador. Também pode incluir a construção da ferramenta de entrada. Tempos separados para essas etapas não foram registrados.

## Outras verificações registradas

Em 2026-10-04, a primeira prova de transferência cobriu o bloco 1 em uma cópia temporária do genesis, não em uma cadeia em execução: uma transferência de 21.000 gas e 385.277 etapas do guest. Três provas levaram 6.33, 6.75 e 6.69 s. O verificador do ZisK e o crate verificador do repositório verificaram a prova. Mudar o chain id da entrada para 1 fez o guest recusá-la sem uma prova.

Construir o guest a partir de uma pasta de build vazia levou 125 s, incluindo o download das dependências. Dois checkouts limpos levaram 133 s e 126 s e produziram o mesmo ELF e programVK entre si. A primeira configuração de programa do provador levou 43 s. Esses números vêm dos registros de 2026-10-04 descritos no relatório de métricas e [README do guest](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md).

Após a demo de 2026-10-05, a verificação no navegador do explorer do bloco 3 passou em 13 ms. Cerca de 0.35 s se passaram do clique até a resposta. Isso foi uma verificação no navegador, não um benchmark, e não está registrado em `demo/results/`.

A verificação em WebAssembly levou de 8 a 32 ms no Node em runners de CI. Esse teste verificou uma prova e depois rejeitou um cabeçalho incompatível. Ele não foi nem uma verificação bem-sucedida de bloco completo nem uma medição no navegador; veja o [README do verificador](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/explorer/verify/README.md).

## O que essas medições não estabelecem

Não há benchmark sistemático de chamadas de contrato ou precompiles, blocos acima de 105 Mgas, ou dos tamanhos de bloco do benchmark com o guest do Ostia. Não há medições com múltiplas GPUs ou múltiplos blocos em andamento.

A construção do witness em um host aquecido, a verificação nativa do sidecar e o commit do Canton de um bloco grande não foram cronometrados separadamente. A demo confirmou blocos com no máximo três transações e uma leg. Cada caso foi executado uma vez, então os resultados não mostram o quanto os tempos variam entre execuções.


---

# 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/measurements.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.
