> 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/tr/rome-zk-evm/trust-model.md).

# Güven modeli

Devnet'te bir Rome ZK EVM zincirini kimin değiştirebileceği ve yatıranların ile çekenlerin nelere güvenmesi gerektiği.

Solana devnet üzerindeki paylaşılan v0.3.0 programları yükseltilebilir. Kanıtlanmış bir kök, yayımlandığında bu programların uyguladığı kurallara göre kesinleşmiş sayılır. Operatörler ve kullanıcılar ayrıca bu kuralları kimin değiştirebileceğini, her zinciri kimin kontrol ettiğini ve veriyi kimin yayımlamayı durdurabileceğini de dikkate almalıdır.

Şunu okuyun: [tam v0.3.0 devnet güven modeli](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) her bir yetkinin tam yetkileri ve mevcut programlardaki kontroller için.

## Rome'un program ve kayıt yetkilileri

Rome, paylaşılan inbox, settlement, Veritas ve bridge programları için yükseltme yetkisini elinde tutar. Devnet'te bu yetki tek imzalıdır. Bir yükseltme, ön bildirim süresi olmaksızın yürürlüğe girebilir ve mevcut herhangi bir program kuralını değiştirebilir. Fon yatırırken bunu bir devnet güven varsayımı olarak değerlendirin.

Rome ayrıca settlement kayıt yetkisini de elinde tutar. Mevcut programlarda, izinsiz kaydı açıp kapatabilir, yeni zincirler için kayıt depozitolarını değiştirebilir, bir protokol üst sınırı olmaksızın mevcut bir zincir için bile settlement ücretlerini değiştirebilir, hazineyi seçebilir, izin verilen zaman damgası sapmasını değiştirebilir ve küresel geri alma penceresini değiştirebilir. Geri alma penceresi, kayıtlı zincirler için kısaltılabilir, ancak mevcut programda 216.000 slotun altına indirilemez.

Kayıt yetkisi, bir zincirin doğrulama anahtarlarının etkinleşme slotunu kaydeder, emekliye ayırır ve değiştirir. Bir ispat, yalnızca o zincir için etkin olan bir anahtara karşı geçerli sayılır. Bu nedenle bu yetki, hangi konuk ispatlarının yeni kökleri kesinleştirebileceğini değiştirebilir veya bir zinciri kullanılabilir anahtarsız bırakabilir. Yeni bir giriş, kayıt işlemi ağa düştüğü anda etkin olabilir. Bir anahtar emekliye ayrıldığında, zaten kesinleşmiş kökler kesin kalır.

Programlar yükseltilmeden, Rome'un anahtarları Rome'un yetkisine sahip olmadığı bir zincir için bir kasa oluşturamaz, o kasanın mint'ini değiştiremez, ödemelerin nereye gideceğini seçemez veya kanıtlanmış bir çıkış olmadan ondan çekim yapamaz. Program yükseltme yetkisi bu kuralları değiştirebilir; bu yüzden kullanıcılar Rome'un devnet'te böyle bir yükseltme yapmayacağına güvenmelidir.

## Zincir yetkiniz

Kurulumda, Solana ödeyicisi aynı zamanda zincir yetkisidir. `./rollup` Girdi kutusu toplu yayını ve kesinleştirmesini, kanıtlanmış kök gönderimini ve zincir yapılandırmasını imzalar. Uygun batch, chunk ve bekleyen kök hesaplarını kapatarak kiralarını geri alabilir. Bu yetkiyi döndürmeye yönelik bir talimat yoktur, bu yüzden onu kaybetmek bu imzalı eylemleri durdurur.

Kayıt, zincirin kimliğini, genesis'ini, inbox programını ve challenge penceresi uzunluğunu sabitler. Yetki, kayıtlı genesis'i düzenleyemez. O genesis içinde bir ücret alıcısı seçer. Yeni bir zincir normalde sıfır bakiyelerle başlar; ilan edilen herhangi bir başlangıç bakiyesi için Rome doğrulama anahtarını kaydetmeden önce karşılık gelen kasa teminatı gerekir. Settlement bunun teminatını kendi başına kontrol etmez.

Yetki, farklı bir çıkış portalı, bridge programı, çekim üst sınırı ve poster teminatı önerebilir. Bir öneri en erken bir zincir challenge penceresi sonra etkin olur. Bu slotun ardından herkes onu etkinleştirebilir. Kullanıcılar çekim yapmadan önce aktif çıkış yapılandırmasını incelemelidir.

İlk kanıtlanmış batch'ten sonra, yetki bir mevduat kuyruğu oluşturabilir ve onun dahil edilme son tarihini, batch başına ve blok başına sınırları, minimum mevduatı, ücreti ve ücret alıcısını seçebilir. Değişikliklerin etkinleşmesi de gecikmeli bir slot ile olur. Mevcut program, hangi bekleyen mevduatların bir **kesinleşmiş** toplu işlemde dışarıda bırakılabileceğini sınırlar. Operatörü o toplu işlemi üretmeye zorlamaz.

## Kullanıcının dayandığı şey

Bir yatıran, sıralayıcıyı çalışır tutması, sıraya alınmış krediyi bir batch'e dahil etmesi, batch'i yayımlaması ve kökünü kanıtlaması için operatöre güvenir. Operatör EVM işlem sırasını seçebilir ve işlemleri reddedebilir; EVM işlemleri için genel bir zorunlu dahil etme hattı yoktur. Bir mevduat bakiyesi, kökü Solana'da kesinleşmeden önce zincir RPC'sinde görünebilir.

Çekim yapan tarafın, çıkış mesajını kapsayan kesin bir köke, aktif bir çıkış yapılandırmasına ve zincir kasasında yeterli wrapped SOL'a ihtiyacı vardır. Operatör bunu batch'leri veya ispatları durdurarak geciktirebilir. Çıkış kanıtlayıcısını durdurarak veya kasa ya da çıkış ödeyicisini fonlamayarak ödemeleri geciktirebilirler. Herkes geçerli bir çıkış ispatı ve release gönderebilir; bu yüzden veri ve kesin kök mevcut olduğunda operatörün çıkış kanıtlayıcısı tek yol değildir.

Mevcut programlarda, settlement bir çıkış ispatını yapılandırılmış portala ve kesin bir köke bağlar. Challenge penceresi başına çıkışları sınırlar ve yeniden oynatmayı engeller. Bridge, alıcıyı kanıtlanmış kayıttan okur ve alıcının ilişkili token hesabını kontrol eder. Release'i kim gönderirse göndersin, ödeme yönünü değiştiremez. Yeterli fonu olmayan bir kasa, çıkış ispatı geçerli olsa bile ödeme yapamaz.

5 SOL kayıt depozitosu, kullanıcı bakiyeleri için teminat değil, bir zincir kayıt teminatıdır. İlk kesin kökten veya on yayımlanmış kökten sonra zincir yetkisine iade edilebilir hale gelir. Geri alma penceresi sona ermeden önce hiçbir kök yayımlanmazsa, herkes zinciri geri alabilir ve iade edilmemiş depozitosu hazineye gider. v0.3.0'daki devnet penceresi, kayıttan itibaren ölçülen 6.480.000 slot, yani yaklaşık 30 gündür.


---

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