> 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/es/canton-zk-evm/measurements.md). # Mediciones Mediciones registradas de la prueba y la liquidación con sus fechas, hardware y límites. El benchmark del prover y las ejecuciones en Ostia midieron distintos guests y cargas de trabajo. El benchmark usó el guest upstream de reth sin modificar. Las ejecuciones en Ostia usaron el guest de este repositorio con su comprobación de chain-rules y la gateway. Esta página describe commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lea el texto completo [informe de métricas](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md) y [resultados de la demostración](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results). ## Hardware Ambos conjuntos usaron una GPU NVIDIA RTX PRO 6000 Blackwell Server Edition. Para la demo de Ostia solo se registraron la GPU y el controlador. | Elemento | Benchmark del prover, 2026-10-03 | Ejecuciones en Ostia, 2026-10-05 | | ------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------- | | CPU | AMD EPYC 9B45, 48 vCPU; un socket, dos hilos por núcleo | No registrado | | RAM del host | 176 GiB según informó el host | No registrado | | Memoria de la GPU | 97.887 MiB, descrita como 96 GB; PCIe gen 5 x16 | Capacidad no registrada | | Controlador | 580.178.04 | 580.178.04 | | CUDA | 13.0 a nivel del controlador; binarios de GPU precompilados, sin toolkit de CUDA instalado | No registrado | | Sistema operativo y disco | Ubuntu 22.04.5, disco de arranque de 500 GB | No registrado | | Node y snarkjs | 20.18.0 y 0.7.6 | No registrado | ## Versiones fijadas Estas son las versiones del repositorio, tal como figuran en el informe de métricas y [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). La versión de Node del host del benchmark anterior difiere de la versión fijada del prover. | Componente | Versión | | --------------------------------------- | ------------------------------------------------------------------ | | ZisK | 1.3.1-alpha | | Fuente del guest upstream | 0.13.1 | | reth | 2.5.2 | | Canton | 3.6.0-snapshot.20260930.20337.0.ve610bc8f | | SDK de Daml para la llamada externa | 3.5.13-snapshot.20261001.145.0.v852bdd82 | | Compilador de Daml | 3.6.0-snapshot.20260915.14804.0.v53478765, orientado a Daml-LF 2.4 | | SDK de Daml para pruebas de Script | 3.5.12, orientado a Daml-LF 2.1 | | Java | 21 | | Rust | 1.94.1 | | Builder y Python de la demo | 3.12 o superior | | Node del prover y snarkjs | 20.20.2 y 0.7.6 | | Node del explorador | 22.18 o superior localmente; 24 en el contenedor y en CI | | Compilador Solidity del token de prueba | 0.8.28 | ## Benchmark del prover: 2026-10-03 La tabla muestra tiempos medianos en segundos de tres ejecuciones en caliente para cada tamaño de bloque. Cada bloque contenía transferencias simples. Todas las pruebas pasaron `cargo-zisk verify`. Los registros sin procesar del benchmark no están en el repositorio. | Bloque | Prueba sin wrap, proceso nuevo | Solo wrap, proceso nuevo | Prueba con wrap, proceso nuevo | Proceso nuevo completo | Prover en ejecución: entrada a prueba envuelta | Prover en ejecución: entrada a prueba verificada | | ------------------------------ | ------------------------------ | ------------------------ | ------------------------------ | ---------------------- | ---------------------------------------------- | ------------------------------------------------ | | 1 transferencia, 21 kgas | 4.6 | 2.4 | 7.4 | 21.1 | 6.7 | 7.0 | | 1.000 transferencias, 21 Mgas | 6.9 | 2.4 | 9.6 | 24.5 | 9.0 | 9.3 | | 5.000 transferencias, 105 Mgas | 17.9 | 2.4 | 20.8 | 34.9 | 21.2 | 21.5 | El prover en ejecución mantuvo cargados el coordinador, el worker y las claves. Los totales de proceso nuevo incluyen el inicio y la detención del prover. Los tiempos de entrada a la prueba comienzan con un archivo witness existente; no miden la construcción del witness. El caso de 105 Mgas fue un benchmark del guest upstream, no un bloque de Ostia. El tope de gas de bloque fijado en Ostia es 30.000.000. | Medición de la prueba | PLONK envuelto | STARK sin envolver | | ---------------------------- | ------------------- | ----------------------- | | Tamaño del archivo de prueba | 2.942 a 2.944 bytes | 415.232 a 415.234 bytes | | `cargo-zisk verify` tiempo | 0,29 a 0,30 s | 0,03 s | | Tamaño de la red | 1,344 bytes | No medido | Verificar la prueba envuelta incluye iniciar Node para ejecutar snarkjs. No es una medición del verificador nativo del sidecar. La forma wire de 1.344 bytes contiene 768 bytes de prueba, 32 bytes de clave del programa, 32 bytes de raíz de recursión y 512 bytes de valores públicos. ## Inicio y memoria Estas mediciones proceden del mismo benchmark del 2026-10-03 con ZisK 1.3.1-alpha. | Medición | Resultado | | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | Primera ejecución de 1 transferencia tras borrar la caché de ZisK y vaciar la caché de página, con la clave de prueba todavía en disco | 123 s de tiempo total; el trabajo de prueba tomó 14,5 s | | Inicio del prover en ejecución con la caché compilada del guest ya presente | Claves cargadas en 7,0 s, luego 9,5 s para registrar el programa | | Primera solicitud de prueba después de ese inicio | 6,56 s | | Memoria máxima de GPU informada por `nvidia-smi` | 93,2 GiB | | Aumento de RAM del host durante una prueba en proceso nuevo | 27 a 29 GiB, más 22,9 GiB de memoria compartida | | Aumento de RAM del host mientras el prover en ejecución atendía solicitudes | 3 GiB, más 22,9 GiB de memoria compartida | | Memoria de GPU informada solo para el wrap PLONK | 30.054.767.337 bytes, unos 28,0 GiB | El prover asigna a la tarjeta un gran búfer de GPU. El uso máximo fue aproximadamente el mismo para los bloques de benchmark más pequeños y más grandes. No establece la memoria mínima de GPU necesaria para todo el prover. ## Demo de Ostia: 2026-10-05 Cada caso se ejecutó una vez en la red local de Canton, con el prover ya en ejecución, desde el commit `6b445073163832e9023850f53678617d90dfc808`. Estos son resultados de pruebas individuales. La [carpeta de resultados](https://github.com/rome-protocol/canton-zk-evm/tree/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/results) contiene los registros. [Resumen](/es/canton-zk-evm/canton-zk-evm.md#what-the-demo-showed) describe los cinco resultados. | Caso | Bloque y gas usado | Prueba | Del archivo de prueba finalizado a la salida del builder | Ejecución completa del builder | | ------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- | -------------------------------------------------------- | ----------------------------------- | | Prueba de humo | Bloque 1, vacío; 0 gas | 6.31 s | 0,49 s | 155,20 s | | Configuración | Bloque 2, dos transacciones; gas no registrado | 6,71 s | No registrado | 8,00 s | | Depósito | Bloque 3, una transacción; 122.308 gas | 6.72 s | 0,66 s | 8,14 s | | Pago | Bloque 4, tres transacciones; 185.307 gas | 6.72 s | 0,42 s | 7,87 s | | Retiro | Bloque 5, una transacción; 90.345 gas | 6.72 s | 0,58 s | 8,02 s | | Asignación retirada | Bloque 6 rechazado, luego reconstruido con una transacción y sin tramos; gas no registrado | 6,75 s para la compilación rechazada; la segunda prueba no se cronometró por separado | Envío rechazado no cronometrado | 8,09 s rechazado; 8,04 s confirmado | | Prueba manipulada | Bloque 7 rechazado; gas no registrado | 6.74 s antes de la alteración | Envío rechazado no cronometrado | 7,57 s | Cada prueba fue de 1.344 bytes. El intervalo desde el archivo de prueba finalizado hasta la salida del builder incluye la obtención de las pruebas de cuenta y de almacenamiento de la gateway, `Avanzar`el commit en ambos participantes confirmantes y a reth marcando el bloque como final. Es más largo que el commit de Canton por sí solo. La correspondencia de legs con los contratos de Canton ocurre antes de la prueba y queda fuera de ese intervalo. La ejecución completa de la prueba de humo incluye la preparación del witness y de la entrada, y la configuración inicial del programa guest por parte del prover. También puede incluir la construcción de la herramienta de entrada. No se registraron tiempos separados para esos pasos. ## Otras comprobaciones registradas El 2026-10-04, la primera prueba de transferencia cubrió el bloque 1 en una copia temporal del genesis, no una cadena en ejecución: una transferencia de 21.000 gas y 385.277 pasos del guest. Tres pruebas tardaron 6,33, 6,75 y 6,69 s. El verificador de ZisK y la crate verificador del repositorio comprobaron la prueba. Cambiar el chain id de entrada a 1 hizo que el guest lo rechazara sin una prueba. Construir el guest desde una carpeta de compilación vacía tomó 125 s, incluida la descarga de dependencias. Dos checkouts nuevos tomaron 133 s y 126 s y produjeron el mismo ELF y programVK entre sí. La primera configuración de programa del prover tomó 43 s. Estas cifras proceden de los registros del 2026-10-04 descritos en el informe de métricas y [README del guest](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md). Después de la demo del 2026-10-05, la comprobación en el navegador del explorador del bloque 3 pasó en 13 ms. Pasaron unos 0,35 s desde el clic hasta la respuesta. Esta fue una sola comprobación en el navegador, no un benchmark, y no está registrada en `demo/results/`. La comprobación de WebAssembly tardó entre 8 y 32 ms en Node en los ejecutores de CI. Esa prueba verificó una prueba y luego rechazó una cabecera no coincidente. No fue ni una comprobación exitosa de bloque completo ni una medición en el navegador; véase el [README del verificador](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/explorer/verify/README.md). ## Lo que estas mediciones no establecen No existe un benchmark sistemático de llamadas a contratos o precompiles, bloques por encima de 105 Mgas, ni de los tamaños de bloque del benchmark con el guest de Ostia. No hay mediciones con múltiples GPU ni con múltiples bloques en vuelo. La construcción del witness en un host en caliente, la verificación nativa del sidecar y el commit de Canton de un bloque grande no se han cronometrado por separado. La demo confirmó bloques con como máximo tres transacciones y un tramo. Cada caso se ejecutó una vez, así que los resultados no muestran cuánto varían los tiempos entre ejecuciones. --- # 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/es/canton-zk-evm/measurements.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.