> 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/trust-model.md).

# Model kepercayaan

Siapa yang dapat mengubah chain Rome ZK EVM di devnet dan apa yang harus dipercaya oleh penyetor dan penarik.

Program bersama v0.3.0 di Solana devnet dapat ditingkatkan. Root yang terbukti bersifat final menurut aturan yang diberlakukan program tersebut saat diposting. Operator dan pengguna juga harus mempertimbangkan siapa yang dapat mengubah aturan itu, siapa yang mengendalikan setiap chain, dan siapa yang dapat menghentikan publikasi data.

Baca [model kepercayaan devnet v0.3.0 lengkap](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) untuk wewenang yang tepat dari setiap otoritas dan pemeriksaan dalam program saat ini.

## Otoritas program dan registry Rome

Rome memegang otoritas peningkatan untuk program inbox bersama, settlement, Veritas, dan bridge. Ini adalah otoritas satu tanda tangan di devnet. Peningkatan dapat berlaku tanpa periode pemberitahuan dan dapat mengubah aturan program apa pun yang ada. Perlakukan ini sebagai asumsi kepercayaan devnet saat menyetor dana.

Rome juga memegang otoritas registry settlement. Dalam program saat ini, otoritas ini dapat menyalakan atau mematikan pendaftaran tanpa izin, mengubah deposit pendaftaran untuk chain baru, mengubah biaya settlement bahkan untuk chain yang sudah ada tanpa batas protokol, memilih treasury, mengubah penyimpangan timestamp yang diizinkan, dan mengubah jendela reclaim global. Jendela reclaim dapat dipersingkat untuk chain yang terdaftar, tetapi tidak di bawah 216.000 slot menurut program saat ini.

Otoritas registry mendaftarkan, menghentikan, dan mengubah slot aktivasi kunci verifikasi sebuah chain. Sebuah bukti hanya dihitung terhadap kunci aktif untuk chain tersebut. Karena itu, otoritas ini dapat mengubah bukti guest mana yang dapat memfinalkan root baru atau membuat sebuah chain tidak memiliki kunci yang dapat digunakan. Entri baru dapat aktif segera setelah transaksi pendaftarannya masuk. Root yang sudah final tetap final saat sebuah kunci dihentikan.

Tanpa memperbarui program, kunci Rome tidak dapat membuat vault untuk chain yang otoritasnya tidak dipegang Rome, mengubah mint vault itu, memilih ke mana pembayarannya dikirim, atau menarik darinya tanpa exit yang terbukti. Otoritas peningkatan program dapat mengubah aturan itu, jadi pengguna harus memercayai Rome untuk tidak melakukan peningkatan seperti itu di devnet.

## Otoritas chain Anda

Dalam `./rollup` setup, payer Solana juga adalah otoritas chain. Ia menandatangani publikasi batch inbox dan finalisasi, posting root yang terbukti, serta konfigurasi chain. Ia dapat menutup akun batch, chunk, dan pending-root yang memenuhi syarat untuk mengambil kembali biaya sewanya. Tidak ada instruksi untuk mengganti otoritas ini, jadi kehilangan otoritas ini akan menghentikan tindakan-tindakan yang ditandatangani tersebut.

Pendaftaran menetapkan ID chain, genesis, program inbox, dan panjang jendela tantangan chain. Otoritas tidak dapat mengedit genesis yang terdaftar. Otoritas memilih penerima biaya dalam genesis itu. Sebuah chain baru biasanya dimulai dengan saldo nol; saldo awal yang diumumkan perlu didukung oleh vault yang sesuai sebelum Rome mendaftarkan kunci verifikasinya. Settlement sendiri tidak memeriksa dukungan tersebut.

Otoritas dapat mengusulkan portal exit yang berbeda, program bridge, batas penarikan, dan jaminan poster. Sebuah proposal menjadi aktif paling cepat satu jendela tantangan chain kemudian. Siapa pun dapat mengaktifkannya setelah slot itu. Pengguna harus memeriksa konfigurasi exit yang aktif sebelum menarik.

Setelah batch pertama yang terbukti, otoritas dapat membuat antrean deposit dan memilih tenggat penyertaannya, batas per batch dan per blok, deposit minimum, biaya, dan penerima biaya. Perubahan juga memiliki slot aktivasi yang tertunda. Program saat ini membatasi deposit yang menunggu mana yang sebuah **terselesaikan** batch boleh tidak menyertakan. Program ini tidak memaksa operator untuk menghasilkan batch tersebut.

## Apa yang diandalkan pengguna

Seorang penyetor mempercayai operator untuk menjaga sequencer tetap berjalan, menyertakan kredit yang diantrekan dalam sebuah batch, memposting batch, dan membuktikan root-nya. Operator dapat memilih urutan transaksi EVM dan menolak transaksi; tidak ada jalur forced-inclusion umum untuk transaksi EVM. Saldo deposit dapat muncul di RPC chain sebelum root-nya final di Solana.

Seorang penarik dana membutuhkan root final yang mencakup pesan exit, konfigurasi exit yang aktif, dan cukup wrapped SOL di vault chain. Operator dapat menunda root itu dengan menghentikan batch atau bukti. Mereka dapat menunda pembayaran dengan menghentikan prover exit atau membiarkan vault atau payer exit kekurangan dana. Siapa pun dapat mengirim bukti exit yang valid dan melepaskan dana, jadi prover exit operator bukan satu-satunya jalur setelah data dan root final tersedia.

Dalam program saat ini, settlement mengikat bukti exit ke portal yang dikonfigurasi dan root final. Program ini membatasi exit per jendela tantangan dan mencegah replay. Bridge membaca penerima dari catatan yang terbukti dan memeriksa token account terkait milik penerima. Siapa pun yang mengirim release tidak dapat mengalihkan pembayarannya. Vault tanpa dana yang cukup tidak dapat membayar, meskipun bukti exit valid.

Deposit pendaftaran 5 SOL adalah jaminan pendaftaran chain, bukan dukungan untuk saldo pengguna. Deposit itu menjadi dapat dikembalikan kepada otoritas chain setelah root final pertama atau sepuluh root yang diposting. Jika tidak ada root yang diposting sebelum jendela reclaim berakhir, siapa pun dapat mengklaim kembali chain dan depositnya yang belum dikembalikan akan masuk ke treasury. Jendela devnet pada v0.3.0 adalah 6.480.000 slot, sekitar 30 hari, dihitung sejak pendaftaran.


---

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