> 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/canton-zk-evm/how-it-works.md).

# Cara kerjanya

Ikuti satu blok Ostia dari reth melalui proses pembuktian hingga commit Canton-nya.

Setiap proses builder membuat, membuktikan, dan mengirimkan satu blok. Canton menentukan apakah blok itu menjadi head berikutnya dari rantai. Sebuah blok EVM dan leg Canton yang dicatatnya dikomit dalam transaksi yang sama.

Halaman ini menjelaskan commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Baca selengkapnya [desain](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md).

```mermaid
flowchart TD
    W["Transaksi EVM"] --> R["reth membangun sesuai permintaan"]
    R --> B["Builder membaca leg gateway dan menemukan kontrak Canton-nya"]
    B -->|"Sebuah leg tidak dapat diselesaikan: keluarkan transaksinya dan bangun ulang"| R
    B -->|"Setiap leg dapat diselesaikan"| P["ZisK membuktikan blok"]
    P --> A["Lanjut: blok, bukti, dan leg dalam satu transaksi Canton"]
    A --> S["Panggilan eksternal: sidecar memeriksa bukti dan status gateway"]
    S --> D["Daml memeriksa head dan menyelesaikan leg"]
    D --> C["Canton mengomit blok dan leg-nya bersama-sama"]
    C --> F["reth menandai blok sebagai final"]
```

## Bangun berdasarkan head Canton

Dompet mengirim transaksi EVM ke reth. Peluncur yang disediakan menjaga penemuan peer tetap mati. reth membuat blok saat builder memintanya.

Builder pertama-tama membaca kontrak aktif `ZkChain` kontrak di Canton. Ia memindahkan head reth, blok aman, dan blok final ke head yang telah dikomit itu. Ia memilih transaksi tertunda berdasarkan harga, menjaga urutan nonce tiap pengirim, dan tetap dalam batas gas. Ia meminta reth untuk membangun dengan daftar transaksi eksplisit itu.

Transaksi EVM yang memerlukan tindakan Canton memanggil gateway. Gateway mencatat sebuah leg dan memasukkannya ke dalam hash berjalan untuk blok itu. Builder membaca event gateway sesuai urutan log dan menemukan kontrak Canton yang diperlukan oleh tiap leg.

Jika suatu alokasi sudah hilang, penerima belum menerima penarikan, atau kontrak lain yang diperlukan tidak ada, builder mengabaikan transaksi itu dan transaksi berikutnya dari pengirim tersebut. Ia mengembalikan reth ke head Canton dan membangun lagi. Pemeriksaan ini terjadi sebelum pembuktian. The [README builder](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) mencantumkan pemeriksaan untuk setiap leg.

## Buktikan blok

Builder menyimpan blok dan saksi eksekusi reth. Alat input menggabungkan blok, saksi, dan genesis ke dalam input prover. ZisK menjalankan guest, yang memvalidasi blok di bawah aturan tetap rantai.

Prover mengembalikan bukti terbungkus berukuran 1.344 byte yang mengikat hash blok. Builder mengirimkan `Maju` dengan header, transaksi, bukti, leg, serta bukti akun dan penyimpanan gateway pada state root blok.

## Periksa dan selesaikan dalam satu transaksi

Setiap peserta yang mengonfirmasi menjalankan sidecar. Panggilan eksternal Canton mengirim blok ke sidecar peserta itu untuk `verifikasi`. Ia memeriksa bukti, kunci program yang dipin, dan rilis ZisK, hash header, serta root daftar transaksi.

Daml memeriksa jawaban terhadap `ZkChain`: induknya harus menjadi head saat ini, nomornya harus yang berikutnya, dan batas gas serta gas yang digunakan harus sesuai dengan batas. Daml membandingkan jawaban sidecar; ia tidak memverifikasi sendiri bukti zero-knowledge.

Daml lalu menulis satu baris untuk setiap leg dari kontrak Canton yang disebutkannya. ID, burner, dan jumlah penarikan berasal dari builder; hash yang dibuktikan mengikatnya pada apa yang dicatat blok. Milik sidecar `bagian` fungsi memeriksa bukti akun dan penyimpanan gateway, meng-hash baris-baris itu secara berurutan, dan membandingkan hasilnya dengan nilai gateway dalam state yang dibuktikan. Blok tanpa leg harus melewati pemeriksaan yang sama dengan daftar kosong.

Daml menyelesaikan leg secara berurutan dan membuat `BlockRecord` dan yang berikutnya `ZkChain`. Canton mengomit perubahan ini bersama-sama. Jika pemeriksaan atau penyelesaian gagal, tidak ada yang dikomit. Mengonsumsi satu kontrak state milik rantai menjadikan Canton sebagai otoritas atas urutan blok. Lihat [antarmuka Daml](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) dan [pemeriksaan sidecar](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md).

## Saat Canton menolak

Setelah Canton mengomit blok, builder menandainya final di reth. Jika Canton menolaknya, builder mengembalikan reth ke blok terakhir yang dikomit Canton dan mengirim transaksi dari blok yang ditolak kembali ke pool. Proses berikutnya memeriksa lagi leg-nya. Pembayaran yang alokasinya telah ditarik kembali diabaikan.

Jika builder kehilangan balasan pengiriman, ia membaca head Canton lagi untuk menentukan apakah blok itu dikomit. Jika pembacaan itu juga gagal, ia melaporkan hasil yang tidak diketahui dan membiarkan reth tetap di tempatnya. Proses berikutnya dimulai dari head Canton. Aturan pemulihan ini ada di [README builder](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#what-one-run-does).


---

# 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/canton-zk-evm/how-it-works.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.