> 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/de/canton-zk-evm/measurements.md). # Messungen Aufgezeichnete Messwerte für Beweis und Abwicklung mit ihren Daten, ihrer Hardware und ihren Grenzen. Der Prover-Benchmark und die Läufe auf Ostia maßen unterschiedliche Gäste und Workloads. Der Benchmark verwendete den unveränderten Upstream-reth-Gast. Die Ostia-Läufe verwendeten den Gast dieses Repositories mit seiner Prüfung der Chain-Regeln und dem Gateway. Auf dieser Seite wird der Commit beschrieben `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lesen Sie das vollständige [Metrikbericht](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md) und [Demo-Ergebnisse](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results). ## Hardware Beide Sätze verwendeten eine NVIDIA RTX PRO 6000 Blackwell Server Edition GPU. Für die Ostia-Demo wurden nur die GPU und der Treiber erfasst. | Posten | Prover-Benchmark, 2026-10-03 | Ostia-Läufe, 2026-10-05 | | ----------------------------- | --------------------------------------------------------------------------------- | ----------------------- | | CPU | AMD EPYC 9B45, 48 vCPUs; ein Socket, zwei Threads pro Kern | Nicht erfasst | | Host-RAM | 176 GiB, wie vom Host gemeldet | Nicht erfasst | | GPU-Speicher | 97.887 MiB, beschrieben als 96 GB; PCIe Gen 5 x16 | Kapazität nicht erfasst | | Treiber | 580.178.04 | 580.178.04 | | CUDA | 13.0 auf Treiberebene; vorkompilierte GPU-Binaries, kein CUDA-Toolkit installiert | Nicht erfasst | | Betriebssystem und Festplatte | Ubuntu 22.04.5, 500-GB-Bootlaufwerk | Nicht erfasst | | Node und snarkjs | 20.18.0 und 0.7.6 | Nicht erfasst | ## Festgelegte Versionen Dies sind die Versionen des Repositories, wie sie im Metrikbericht aufgeführt sind und [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). Die oben genannte Node-Version des Benchmark-Hosts weicht von der festgelegten Version des Provers ab. | Komponente | Version | | -------------------------------- | -------------------------------------------------------------------- | | ZisK | 1.3.1-alpha | | Upstream-Gastquelle | 0.13.1 | | reth | 2.5.2 | | Canton | 3.6.0-snapshot.20260930.20337.0.ve610bc8f | | Daml-SDK für den externen Aufruf | 3.5.13-snapshot.20261001.145.0.v852bdd82 | | Daml-Compiler | 3.6.0-snapshot.20260915.14804.0.v53478765, ausgelegt auf Daml-LF 2.4 | | Daml-SDK für Script-Tests | 3.5.12, ausgelegt auf Daml-LF 2.1 | | Java | 21 | | Rust | 1.94.1 | | Builder und Demo-Python | 3.12 oder neuer | | Prover-Node und snarkjs | 20.20.2 und 0.7.6 | | Explorer-Node | lokal 22.18 oder neuer; 24 im Container und in CI | | Solidity-Compiler für Test-Token | 0.8.28 | ## Prover-Benchmark: 2026-10-03 Die Tabelle zeigt Medianzeiten in Sekunden aus drei Warm-Runs für jede Blockgröße. Jeder Block enthielt einfache Transfers. Jeder Beweis bestand cargo-zisk verify. Die rohen Benchmark-Logs sind nicht im Repository. `cargo-zisk verify`. Die rohen Benchmark-Logs sind nicht im Repository. | Block | Beweis ohne Wrap, frischer Prozess | Nur Wrap, frischer Prozess | Beweis mit Wrap, frischer Prozess | Gesamter frischer Prozess | Prover läuft: Eingabe für gewrappten Beweis | Prover läuft: Eingabe für verifizierten Beweis | | ------------------------- | ---------------------------------- | -------------------------- | --------------------------------- | ------------------------- | ------------------------------------------- | ---------------------------------------------- | | 1 Transfer, 21 kgas | 4.6 | 2.4 | 7.4 | 21.1 | 6.7 | 7.0 | | 1.000 Transfers, 21 Mgas | 6.9 | 2.4 | 9.6 | 24.5 | 9.0 | 9.3 | | 5.000 Transfers, 105 Mgas | 17.9 | 2.4 | 20.8 | 34.9 | 21.2 | 21.5 | Der laufende Prover behielt Koordinator, Worker und Schlüssel geladen. Die Gesamtsummen für den frischen Prozess umfassen das Starten und Stoppen des Provers. Zeiten von Eingabe bis Beweis beginnen mit einer vorhandenen Witness-Datei; das Erstellen des Witnesses wird nicht gemessen. Der Fall mit 105 Mgas war ein Benchmark des Upstream-Gasts, kein Ostia-Block. Ostias festgelegte Block-Gas-Grenze beträgt 30.000.000. | Beweismessung | Gewrapptes PLONK | Ungewrapptes STARK | | ------------------------ | -------------------- | ------------------------ | | Größe der Beweisdatei | 2.942 bis 2.944 Byte | 415.232 bis 415.234 Byte | | `cargo-zisk verify` Zeit | 0,29 bis 0,30 s | 0,03 s | | Wire-Größe | 1.344 Bytes | Nicht gemessen | Das Verifizieren des gewrappten Beweises umfasst das Starten von Node, um snarkjs auszuführen. Es ist keine Messung des nativen Verifizierers des Sidecars. Die 1.344-Byte-Wire-Form enthält 768 Byte Beweis, 32 Byte Programmschlüssel, 32 Byte Rekursionswurzel und 512 Byte öffentliche Werte. ## Start und Speicher Diese Messungen stammen aus demselben Benchmark vom 2026-10-03 mit ZisK 1.3.1-alpha. | Messung | Ergebnis | | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Erster 1-Transfer-Lauf nach dem Löschen des ZisK-Caches und dem Leeren des Page-Caches, wobei der Proving-Key noch auf der Festplatte lag | 123 s Gesamtzeit; die Beweisarbeit dauerte 14,5 s | | Start des laufenden Provers, wobei der kompilierte Cache des Gasts bereits vorhanden war | Schlüssel in 7,0 s geladen, dann 9,5 s bis zur Registrierung des Programms | | Erste Beweisanfrage nach diesem Start | 6,56 s | | Gemeldeter Spitzenwert des GPU-Speichers von `nvidia-smi` | 93,2 GiB | | Anstieg des Host-RAM während eines Beweises im frischen Prozess | 27 bis 29 GiB, plus 22,9 GiB Shared Memory | | Anstieg des Host-RAM, während der laufende Prover Anfragen bediente | 3 GiB, plus 22,9 GiB Shared Memory | | Für den PLONK-Wrap allein gemeldeter GPU-Speicher | 30.054.767.337 Byte, etwa 28,0 GiB | Der Prover dimensioniert einen großen GPU-Puffer auf die Karte. Die Spitzennutzung war bei den kleinsten und größten Benchmark-Blöcken ungefähr gleich. Daraus lässt sich nicht der minimale GPU-Speicherbedarf für den gesamten Prover ableiten. ## Ostia-Demo: 2026-10-05 Jeder Fall lief einmal im lokalen Canton-Netzwerk, wobei der Prover bereits lief, ab Commit `6b445073163832e9023850f53678617d90dfc808`. Dies sind einzelne Testergebnisse. Die [Ergebnisordner](https://github.com/rome-protocol/canton-zk-evm/tree/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/results) enthält die Aufzeichnungen. [Überblick](/de/canton-zk-evm/canton-zk-evm.md#what-the-demo-showed) beschreibt die fünf Ergebnisse. | Fall | Block und verwendetes Gas | Beweis | Von der fertigen Beweisdatei bis zum Beenden des Builders | Gesamter Builder-Lauf | | ------------------------ | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------- | ---------------------------------- | | Smoke | Block 1, leer; 0 Gas | 6,31 s | 0,49 s | 155,20 s | | Einrichtung | Block 2, zwei Transaktionen; Gas nicht erfasst | 6,71 s | Nicht erfasst | 8,00 s | | Einzahlung | Block 3, eine Transaktion; 122.308 Gas | 6,72 s | 0,66 s | 8,14 s | | Zahlung | Block 4, drei Transaktionen; 185.307 Gas | 6,72 s | 0,42 s | 7,87 s | | Auszahlung | Block 5, eine Transaktion; 90.345 Gas | 6,72 s | 0,58 s | 8,02 s | | Zuordnung zurückgenommen | Block 6 abgelehnt, dann mit einer Transaktion und ohne Legs neu erstellt; Gas nicht erfasst | 6,75 s für den abgelehnten Build; zweiter Beweis nicht separat gemessen | Abgelehnte Übermittlung nicht gemessen | 8,09 s abgelehnt; 8,04 s committed | | Manipulierter Beweis | Block 7 abgelehnt; Gas nicht erfasst | 6,74 s vor der Manipulation | Abgelehnte Übermittlung nicht gemessen | 7,57 s | Jeder Beweis war 1.344 Byte groß. Das Intervall von der fertigen Beweisdatei bis zum Beenden des Builders umfasst das Abrufen der Konto- und Speichernachweise des Gateways, `Vorschuss`Commit auf beiden bestätigenden Teilnehmern und reth, das den Block als endgültig markiert. Es ist länger als Cantons Commit allein. Das Zuordnen der Legs zu Canton-Verträgen geschieht vor dem Beweisen und liegt außerhalb dieses Intervalls. Der gesamte Lauf des Smoke-Tests umfasst die Vorbereitung von Witness und Eingabe sowie die anfängliche Einrichtung des Gastprogramms durch den Prover. Er kann auch das Erstellen des Eingabetools umfassen. Separate Zeiten für diese Schritte wurden nicht erfasst. ## Weitere erfasste Prüfungen Am 2026-10-04 deckte der erste Transfer-Beweis Block 1 auf einer temporären Kopie des Genesis ab, nicht auf einer laufenden Chain: ein Transfer mit 21.000 Gas und 385.277 Gast-Schritten. Drei Beweise dauerten 6,33, 6,75 und 6,69 s. Der Verifizierer von ZisK und das Verifizierer-Crate des Repositories prüften den Beweis. Das Ändern der Chain-ID der Eingabe auf 1 veranlasste den Gast, sie ohne Beweis abzulehnen. Das Erstellen des Gasts aus einem leeren Build-Ordner dauerte 125 s, einschließlich des Herunterladens der Abhängigkeiten. Zwei frische Checkouts dauerten 133 s und 126 s und erzeugten jeweils dasselbe ELF und programVK. Das erste Program-Setup des Provers dauerte 43 s. Diese Werte stammen aus den am 2026-10-04 erfassten Aufzeichnungen, die im Metrikbericht und [README des Gasts](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md). Nach der Demo am 2026-10-05 bestand die Browser-Prüfung des Explorers für Block 3 in 13 ms. Vom Klick bis zur Antwort vergingen etwa 0,35 s. Dies war eine einzelne Browser-Prüfung, kein Benchmark, und ist nicht in `demo/results/`. Die WebAssembly-Prüfung dauerte in Node auf CI-Runnern 8 bis 32 ms. Dieser Test verifizierte einen Beweis und lehnte dann einen nicht übereinstimmenden Header ab. Es war weder eine erfolgreiche vollständige Blockprüfung noch eine Browser-Messung; siehe das [README des Verifizierers](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/explorer/verify/README.md). ## Was diese Messungen nicht belegen Es gibt keinen systematischen Benchmark von Vertragsaufrufen oder Precompiles, von Blöcken über 105 Mgas oder von den Blockgrößen des Benchmarks mit Ostias Gast. Es gibt keine Messungen mit mehreren GPUs oder mehreren gleichzeitig in Arbeit befindlichen Blöcken. Witness-Erstellung auf einem warmen Host, native Sidecar-Verifizierung und Cantons Commit eines großen Blocks wurden nicht separat gemessen. Die Demo commitete Blöcke mit höchstens drei Transaktionen und einem Leg. Jeder Fall lief einmal, daher zeigen die Ergebnisse nicht, wie stark die Zeiten zwischen den Läufen variieren. --- # 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/de/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.