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

# Cara kerjanya

Ikuti sebuah blok EVM melalui posting data ke Solana, pembuktian ZisK, dan penyelesaian akhir.

Sequencer Anda menerima transaksi EVM melalui JSON-RPC. Ia memeriksa tanda tangan, nonce, dana, dan gas, lalu mengeksekusi transaksi yang diterima sesuai urutan kedatangan. Ia menulis sub-blok yang ditandatangani dan transaksi di dalamnya ke log terurut yang tahan lama sebelum mengembalikan pra-konfirmasi. Sequencer menyematkan reth untuk menghasilkan blok chain.

Pra-konfirmasi memberi tahu Anda apa yang diterima dan diurutkan oleh sequencer. Itu bukan root Solana final. Sisa jalurnya menerbitkan data dan membuktikan bahwa mengeksekusinya menghasilkan state yang diklaim.

```
Transaksi EVM -> sequencer -> log terurut -> batcher -> inbox Solana
Inbox Solana -> derive -> reth-verifier -> blok + saksi
blok + saksi -> prover (guest batch ZisK) -> bukti + root
bukti + root -> penyelesaian Solana (PostRootProved) -> root final
```

## Dari blok ke batch inbox

Batcher membaca blok-blok berurutan dari log terurut. Contohnya `chain.toml` menutup sebuah batch pada 60 blok, atau 60 detik setelah blok pertamanya, mana pun yang lebih dulu. Ia memampatkan batch menjadi frame, mengirim frame tersebut sebagai potongan inbox di Solana, lalu memfinalisasi komitmen Merkle batch.

Komitmen inbox mencakup ID chain dan batch, slot pembukaan, jumlah chunk, root Merkle dari chunk, dan rentang deposit batch. Memfinalisasi batch inbox berarti datanya telah diposting. Itu tidak menjadikan state root-nya final. Otoritas chain menandatangani finalisasi batch.

Batcher tidak dapat melewati nomor blok. Penyelesaian juga mengambil batch berikutnya secara berurutan. Itulah sebabnya batch yang macet atau ditinggalkan memblokir root-root berikutnya. Batcher melanjutkan batch yang ditulis sebagian dengan nomor yang sama setelah restart ketika ia dapat merekonstruksinya.

## Turunkan, verifikasi, dan buktikan

`Turunkan` membaca batch inbox yang telah difinalisasi dari Solana. Ia merekonstruksi blok-blok dan menjalankan sebuah `reth-verifier` node untuk mengeksekusinya lagi. Node ini menyediakan saksi eksekusi yang dibutuhkan batch prover dan bukti state yang dibutuhkan exit prover. Ia menjalankan API pengujian reth, jadi harus tetap tidak terhubung ke jaringan publik.

Prover membaca setiap batch inbox yang telah difinalisasi, memperoleh blok dan saksi dari node verifier, dan menjalankan guest batch chain di ZisK. Guest memeriksa bahwa blok cocok dengan data inbox dan dieksekusi dengan benar. Ia mengomitmenkan nilai publik batch, termasuk state root yang dihasilkan. Genesis dan fee recipient Anda dikompilasi ke dalam guest ini, sehingga setiap chain memiliki guest dan `programVK`.

Prover memeriksa bukti secara lokal, lalu mengirim `PostRootProved`. Program penyelesaian memeriksa kunci verifikasi aktif yang terdaftar untuk chain ini dan rilis ZisK yang dinamai oleh kunci tersebut. Program ini juga memeriksa nilai publik bukti terhadap ID chain, rentang blok, pendahulu, komitmen inbox, dan root yang diklaim.

Veritas adalah verifier Rome untuk bukti ZisK PLONK. Penyelesaian menautkan kode verifikasinya dan menjalankannya di dalam `PostRootProved`; ia tidak memanggil program Veritas yang diterapkan secara terpisah. Bukti yang valid menulis sebuah `Final` root dan memajukan finality head dalam transaksi Solana yang sama. Root genesis dari chain permissionless tidak final dengan sendirinya. Root final pertamanya memerlukan batch yang telah dibuktikan.

## Dana yang melintasi batas

Setoran dimulai di Solana. Program bridge memindahkan token yang disetor dari penyetor ke brankas chain tersebut dan menambahkan catatan setoran bernomor. Sequencer membaca setoran Solana yang telah difinalisasi dan mengkredit alamat EVM yang disebutkan secara berurutan. Batcher mengomitmenkan rentang setoran bersama batch. Saldo muncul di chain ketika bloknya tersegel, tetapi kreditnya baru final ketika root batch tersebut dibuktikan di Solana.

Penarikan dimulai di chain pada portal exit-nya. Portal mencatat pesan dan membakar aset native. Exit prover memantau pesan itu dan memperoleh bukti penyimpanan Ethereum dari node verifier terhadap root final. Ia memeriksa bukti itu secara lokal, lalu mengirim `ProveExit` ke penyelesaian Solana.

Penyelesaian memeriksa portal, pesan, root final, dan batas exit, serta mencegah exit yang sama dibuktikan dua kali. Exit prover kemudian mengirim transaksi pelepasan bridge. Bridge mengonsumsi exit yang telah dibuktikan dan membayar penerima dari brankas chain tersebut dalam satu transaksi atomik. Penerima berasal dari catatan yang telah dibuktikan, jadi orang yang mengirim pelepasan tidak dapat mengubahnya.

Baca selengkapnya [arsitektur v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.md) untuk format wire, batas-batas komponen, dan pemeriksaan pada setiap instruksi.


---

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