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

# 신뢰 모델

devnet에서 Rome ZK EVM 체인을 누가 변경할 수 있는지, 그리고 입금자와 출금자가 무엇을 신뢰해야 하는지.

Solana devnet의 공유 v0.3.0 프로그램은 업그레이드 가능합니다. 입증된 루트는 게시될 때 해당 프로그램이 강제하는 규칙에 따라 최종 확정됩니다. 운영자와 사용자도 누가 그 규칙을 변경할 수 있는지, 누가 각 체인을 통제하는지, 그리고 누가 데이터 게시를 중단할 수 있는지를 고려해야 합니다.

다음을 읽어 보세요 [전체 v0.3.0 devnet 신뢰 모델](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) 각 권한자의 정확한 권한과 현재 프로그램의 검증 절차를 확인하려면.

## Rome의 프로그램 및 레지스트리 권한

Rome는 공유 inbox, settlement, Veritas 및 bridge 프로그램에 대한 업그레이드 권한을 보유합니다. 이는 devnet에서 단일 서명 권한입니다. 업그레이드는 사전 고지 기간 없이 적용될 수 있으며 현재 프로그램 규칙을 변경할 수 있습니다. 자금을 예치할 때 이를 devnet 신뢰 가정으로 간주하세요.

Rome는 또한 settlement 레지스트리 권한도 보유합니다. 현재 프로그램에서는 무허가 등록을 켜거나 끌 수 있고, 새 체인의 등록 예치금을 변경할 수 있으며, 프로토콜 상한 없이 기존 체인의 settlement 수수료도 변경할 수 있고, 금고를 선택하고, 허용되는 타임스탬프 편차를 변경하고, 전역 회수 기간을 변경할 수 있습니다. 회수 기간은 등록된 체인에 대해 단축할 수 있지만, 현재 프로그램에서는 216,000 슬롯 아래로는 줄일 수 없습니다.

레지스트리 권한은 체인의 검증 키를 등록, 폐기 및 활성화 슬롯 변경합니다. 증명은 해당 체인의 활성 키에 대해서만 유효합니다. 따라서 이 권한은 어떤 게스트의 증명이 새 루트를 최종 확정할 수 있는지 바꾸거나, 체인에 사용할 수 있는 키가 없게 만들 수 있습니다. 새 항목은 등록 트랜잭션이 도착하는 즉시 활성화될 수 있습니다. 이미 최종 확정된 루트는 키가 폐기되어도 그대로 최종 상태로 유지됩니다.

프로그램을 업그레이드하지 않는 한, Rome의 키는 Rome가 권한을 보유하지 않은 체인에 대해 볼트를 생성할 수 없고, 해당 볼트의 민트를 변경할 수 없으며, 지급금이 어디로 가는지 선택할 수 없고, 입증된 종료 없이 그 볼트에서 인출할 수도 없습니다. 프로그램 업그레이드 권한은 이러한 규칙을 변경할 수 있으므로, 사용자들은 Rome가 devnet에서 그런 업그레이드를 하지 않을 것이라고 신뢰해야 합니다.

## 귀하의 체인 권한

에서 `./rollup` 설정에서는 Solana payer가 또한 체인 권한입니다. 이 권한은 inbox 배치 게시와 최종 확정, 입증된 루트 게시, 그리고 체인 구성을 서명합니다. 적격한 batch, chunk 및 pending-root 계정을 닫아 해당 렌트를 회수할 수 있습니다. 이 권한을 교체하는 지침은 없으므로, 이를 잃으면 이러한 서명된 작업이 중단됩니다.

등록은 체인의 ID, 제네시스, inbox 프로그램 및 챌린지 윈도 길이를 고정합니다. 권한은 등록된 제네시스를 수정할 수 없습니다. 해당 제네시스에서 수수료 수령자를 선택합니다. 새 체인은 일반적으로 잔액 0으로 시작하며, 선언된 시작 잔액은 Rome가 해당 검증 키를 등록하기 전에 일치하는 볼트 담보가 필요합니다. settlement 자체는 그 담보를 확인하지 않습니다.

권한은 다른 종료 포털, bridge 프로그램, 인출 한도 및 포스터 보증금을 제안할 수 있습니다. 제안은 최소 한 체인 챌린지 윈도 후에야 활성화됩니다. 그 슬롯 이후에는 누구나 이를 활성화할 수 있습니다. 사용자는 인출 전에 활성화된 종료 구성을 확인해야 합니다.

첫 번째 입증된 배치 이후, 권한은 예치 큐를 생성하고 포함 마감 시각, 배치당 및 블록당 한도, 최소 예치금, 수수료 및 수수료 수령자를 선택할 수 있습니다. 변경 사항에도 지연된 활성화 슬롯이 적용됩니다. 현재 프로그램은 어떤 대기 중인 예치금이 a **최종 확정된** 해당 배치는 제외할 수 있습니다. 이는 운영자가 그 배치를 생성하도록 강제하지 않습니다.

## 사용자가 의존하는 것

예치자는 운영자가 시퀀서를 계속 실행하고, 대기열에 있는 크레딧을 배치에 포함하고, 배치를 게시하며, 그 루트를 입증할 것이라고 신뢰합니다. 운영자는 EVM 트랜잭션 순서를 선택하고 트랜잭션을 거부할 수 있으며, EVM 트랜잭션에 대한 일반적인 강제 포함 경로는 없습니다. 예치 잔액은 Solana에서 루트가 최종 확정되기 전에 체인 RPC에 나타날 수 있습니다.

인출자는 종료 메시지를 포함하는 최종 루트, 활성 종료 구성, 그리고 체인 볼트에 충분한 wrapped SOL이 필요합니다. 운영자는 배치나 증명을 중단하여 해당 루트를 지연시킬 수 있습니다. 운영자는 종료 증명자를 중단하거나 볼트 또는 종료 지불자에 자금을 공급하지 않아 지급을 지연시킬 수 있습니다. 누구나 유효한 종료 증명과 릴리스를 제출할 수 있으므로, 데이터와 최종 루트가 उपलब्ध하면 운영자의 종료 증명자만이 유일한 경로는 아닙니다.

현재 프로그램에서는 settlement가 종료 증명을 구성된 포털과 최종 루트에 연결합니다. 이는 챌린지 윈도당 종료를 제한하고 재생 공격을 방지합니다. bridge는 입증된 기록에서 수신자를 읽고 수신자의 연관 토큰 계정을 확인합니다. 릴리스를 보내는 사람은 지급 대상을 다른 곳으로 돌릴 수 없습니다. 자금이 충분하지 않은 볼트는 종료 증명이 유효하더라도 지급할 수 없습니다.

5 SOL 등록 예치금은 체인 등록 보증금이며, 사용자 잔액을 뒷받침하는 자금이 아닙니다. 이는 첫 번째 최종 루트 또는 10개의 게시된 루트 이후 체인 권한에게 환불 가능해집니다. 회수 기간이 끝나기 전에 루트가 게시되지 않으면 누구나 체인을 회수할 수 있으며, 환불되지 않은 예치금은 금고로 이동합니다. v0.3.0의 devnet 윈도는 등록 시점부터 측정하며 6,480,000 슬롯, 약 30일입니다.


---

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