> 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/id/rome-zk-evm/prover-host.md). # Host prover Ukuran dan siapkan host GPU yang membuktikan batch Rome ZK EVM dengan ZisK 1.3.1-alpha. Node dapat mengurutkan transaksi dan memposting batch tanpa GPU. Ia memerlukan prover untuk membuat root apa pun menjadi final di Solana. Pada v0.3.0, prover menjalankan ZisK 1.3.1-alpha dengan guest yang dibangun untuk genesis chain Anda. Ia membuktikan batch inbox satu per satu, memeriksa setiap bukti secara lokal, lalu mempostingnya ke penyelesaian. Panduan [panduan lengkap prover-host](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) memiliki langkah-langkah penyiapan dan pemulihan. Gunakan bersama dengan [runbook devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## Tentukan ukuran host Gunakan x86-64 Ubuntu 22.04 atau yang lebih baru dan satu GPU NVIDIA dengan memori lebih dari 30 GB. Skrip penyiapan menerima GPU dengan sekitar 32,2 GB atau lebih. Langkah proof akhir meminta sekitar 30 GB, jadi kartu 24 GB terlalu kecil. Driver NVIDIA harus minimal 525.60.13. Setidaknya **128 GB RAM** dan **125 GB ruang disk kosong** di lokasi instalasi ZisK. Arsip kunci pembuktian 1.3.1-alpha berukuran 5,1 GB dan arsip kunci PLONK berukuran 21,9 GB. Setelah penyiapan menghasilkan file konstanta-nya, dua direktori kunci berukuran 21 GiB dan 26 GiB. Proof pertama menambahkan file cache. Host CPU tercatat 102,1 GB total setelah satu proof, dan pertumbuhan cache GPU belum diukur. Pustaka pembuktian 1.3.1-alpha melaporkan 24,7 GB untuk buffer kerja utamanya dan 5,6 GB untuk rekursi pada batch sekitar 3 juta langkah. Puncak seluruh proses pada rilis ini tidak dicatat. Run GPU devnet menggunakan host dengan RAM 176 GB; penggunaan RAM puncaknya juga tidak dicatat. Gunakan 128 GB sebagai perkiraan ukuran, bukan puncak yang diukur. ## Apa yang diukur Satu batch yang hampir kosong memakan waktu sekitar **17 detik**, termasuk wrap PLONK, pada host dengan satu **RTX PRO 6000 96 GB**, 48 inti CPU dan 176 GB RAM. Sekitar 95 GB memori GPU terlihat sedang digunakan. Itulah yang ditahan run ini, bukan memori GPU minimum untuk setiap batch. Batch yang lebih besar belum diukur waktunya di GPU. Rome menyelesaikan 116 batch devnet yang hampir kosong dalam sekitar 35 menit pada GPU itu. Itu penting ketika sebuah chain telah menghasilkan blok kosong sambil menunggu kunci verifikasinya: prover harus memprosesnya secara berurutan sebelum bisa mencapai state yang lebih baru. ## Jalankan skrip penyiapan Pasang driver NVIDIA dan reboot jika perlu. Dari root repositori, jalankan skrip rilis sebagai root. Setel `ZISK_HOME` ke direktori tempat ZisK dan kuncinya akan berada. Gunakan nilai yang sama di rollup Anda `.env`: ```sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh --check ``` Skrip ini memasang build GPU ZisK, kunci pembuktian dan PLONK-nya, pustaka sistem yang dibutuhkannya, dan runtime NVIDIA Docker. Skrip ini menetapkan batas memori terkunci menjadi tak terbatas. Keluar lalu masuk lagi agar batas itu berlaku untuk shell Anda. Setelah itu, skrip memeriksa GPU dan driver, biner yang terpasang, kunci, batas memori, dan runtime container. Sebelum menjalankan installer, skrip memeriksa SHA-256 installer. Skrip memeriksa kedua arsip kunci sebelum mengekstrak salah satunya, dan memeriksa yang terpasang `cargo-zisk` dan `cargo-zisk-dev` biner GPU sebelum skrip menjalankannya. Skrip ini menghasilkan file konstanta yang diperlukan untuk agregasi dan pembuktian PLONK. Jika suatu run gagal, jalankan skrip lagi. Skrip melewati unduhan kunci ketika kunci yang terpasang sudah cocok dengan manifest yang dipatok. Skrip ini tidak memeriksa setiap bagian instalasi ZisK. Installer mengambil bundel biner dan menjalankan installer toolchain-nya sebelum skrip memeriksa dua biner GPU yang terpasang. Eksekutabel dan file sumber lain dalam bundel itu tidak diperiksa hash-nya oleh skrip ini. Panduan lengkap menjelaskan batasan ini dan memiliki perintah untuk memeriksa setiap unduhan secara terpisah. ## Hubungkan ke chain Anda Prover memerlukan guest ELF yang cocok, metadata verifikasinya, dan kunci pembuktian 1.3.1-alpha yang sama. Setel `PROVER=on` dan pengaturan guest serta ZisK dalam konfigurasi rollup, lalu jalankan `./rollup init` dan `./rollup up`. Run pertama membangun image prover dari sumber v0.3.0. Image node saja tidak berisi prover. Sebelum setiap start, prover memeriksa kunci pembuktian yang terpasang terhadap manifest SHA-256 yang dipatok. Pemeriksaan itu mencakup nama file dan isi. File constant-tree dan constant GPU yang dihasilkan dikecualikan karena berbeda menurut host. Ketidaksesuaian menghentikan prover dengan `KeysShaMismatch`. Jangan ubah manifest hanya agar instalasi yang tidak cocok bisa mulai; pasang rilis yang cocok dengan guest chain dan kunci terdaftar. Jalankan `./rollup check` setelah memulai. Skrip memeriksa layanan prover, kunci verifikasi aktif, dan lag settlement dan prover. [panduan pemantauan](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) mencantumkan metrik lokal dan kondisi peringatan yang berguna. --- # 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/id/rome-zk-evm/prover-host.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.