> 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/run-a-rollup.md).

# 롤업 실행

v0.3.0 롤업 러너로 Solana devnet에서 자신만의 Rome ZK EVM 체인을 등록하고 실행하세요.

위의 `./rollup` 러너는 Rome의 공유 Solana devnet 프로그램을 대상으로 하나의 체인을 시작합니다. 노드를 직접 실행하고 Solana 비용을 지불합니다. 정산 프로그램은 직접 배포하지 않습니다. 등록은 허가 없이 가능하지만, 증명된 루트에는 Rome에 의해 등록된 체인별 검증 키가 필요합니다.

이 페이지는 다음을 사용합니다 **v0.3.0**. 이 [전체 devnet 가이드](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) 모든 설정, 실패 및 복구 단계를 다룹니다.

## 시작하기 전에

bash 4 이상, Git, Docker Engine 28 이상(Compose 포함), curl, jq, openssl, Solana CLI, Python 3.11 이상이 있는 x86-64 Linux 머신을 사용하세요. Solana devnet RPC 엔드포인트, 자금이 충전된 Solana payer 키페어(이 키페어가 체인 권한자이기도 함), 그리고 시퀀서 서명 키가 필요합니다. 두 파일은 모두 비공개로 유지하고 컨테이너 사용자 999가 읽을 수 있어야 합니다. 이 가이드에서 만드는 방법을 설명합니다.

예산은 약 **devnet의 7 SOL** 을 payer용으로 잡으세요. 등록 시 5 SOL이 잠깁니다; `./rollup check` 게시와 렌트를 위해 최소 1 SOL이 남아 있어야 합니다. 첫 최종 루트 또는 게시된 루트 10개 후에 예치금은 환불 가능해집니다. 그 전에 체인이 회수되면 예치금은 재무로 들어갑니다. 체인에는 사용자가 제어하는 EVM 수수료 수신 주소도 필요합니다.

루트를 정산하려면 30GB를 넘는 메모리를 가진 NVIDIA GPU 1개가 있는 프로버 호스트가 필요합니다. 24GB 카드로는 최종 증명 단계에 충분하지 않습니다. [프로버 호스트](/ko/rome-zk-evm/prover-host.md) 는 RAM과 디스크 예산을 제공합니다. 프로버가 준비되기 전에도 노드는 실행하고 배치를 게시할 수 있지만, 그 루트들은 어느 것도 최종이 아닙니다.

## 노드를 시작합니다

릴리스를 클론하고 해당 rollup 디렉터리에서 작업하세요:

```sh
git clone --branch v0.3.0 https://github.com/rome-protocol/solana-zk-evm.git
cd solana-zk-evm/deploy/rollup
cp .env.example .env
cp chain.toml.example chain.toml
```

Solana RPC, 서명자 위치를 설정하고 `ROME_ZK_TAG=v0.3.0` 에서 `.env`. 유지하세요 `PROGRAMS_JSON=programs.devnet.json`. 다음을 설정하세요 `ROME_ZK_GUEST_TAG=v0.3.0` 및 `ZISK_RELEASE=1.3.1-alpha` 나중의 guest 빌드를 위해 사용합니다. 로컬 첫 실행에서는 RPC를 loopback에 바인딩해 두세요. 다음은 비워 두세요 `PROVER` guest와 해당 키가 준비될 때까지 설정하지 마세요.

설정하세요 `genesis.fee_recipient` 에서 `chain.toml` 을 EVM 주소로 설정하세요. 체인 ID는 선택하지 마세요. 정산은 payer와 그 등록 횟수로부터 ID를 도출합니다; `init` 는 아무것도 보내기 전에 이를 읽습니다. 모든 ID의 약 절반은 MetaMask에 비해 너무 큽니다. 만약 당신의 ID가 그런 경우라면, `init` 은 다음으로 중단됩니다 `ChainIdNotWalletSafe`; 새 payer 키를 만들고 `PAYER_KEYPAIR_PATH` 를 그 키로 가리킨 다음 `init` 를 다시 실행하세요.

새 체인은 잔액이 0인 상태로 시작합니다. 예치가 열리기 전에 가스가 필요하다고 back된 잔액 하나를 선언한다면, 검증 키를 요청하기 전에 동일한 양의 wrapped SOL을 체인의 금고에 잠가 두세요.

```sh
./rollup init
./rollup register --dry-run
./rollup register --confirm
./rollup up
./rollup check
```

`init` 는 genesis 및 서비스 구성을 렌더링합니다. `register --confirm` 은 5 SOL 예치금을 잠그고 배치 커서를 생성합니다. `up` 는 시퀀서, 배처, derive 및 verifier 노드를 시작합니다. `check` 는 누락된 서비스를 이름으로 알려주고, 이어서 체인 ID, 헤드, 배처의 진행 상황, inbox, 루트를 비교합니다. 배치가 닫힐 시간을 가진 뒤 다시 실행하세요; 첫 배치 진행 상황 확인은 샘플만 기록합니다.

프로버가 없으면 시퀀서는 RPC를 제공하고, 배처는 트랜잭션 데이터를 inbox에 게시하며, derive는 체인을 재구성합니다. inbox 배치는 최종 정산 루트가 아닙니다. genesis 루트조차 증명을 기다립니다.

## 배치에서 최종 루트로 전환

체인의 genesis를 위한 guest를 빌드하세요:

```sh
./rollup guest-build
```

이 빌드는 v0.3.0 guest와 ZisK 1.3.1-alpha를 사용합니다. 체인의 guest 프로그램과 검증 키 메타데이터를 생성합니다. programVK를 계산하려면 ZisK 증명 키와 약 36GB의 RAM이 필요합니다. 체인을 등록한다고 해서 검증 키가 등록되는 것은 아닙니다. 빌드 후 검증 키 요청을 보내세요. `programVK` 에는 ZisK proving key와 약 36GB의 RAM이 필요합니다. 체인을 등록해도 검증 키가 등록되지는 않습니다. 다음을 보내세요 [검증 키 요청](/ko/rome-zk-evm/verification-key.md) 을 빌드 후에 보내세요. Rome이 genesis와 guest를 확인한 뒤, 활성화 슬롯과 함께 키를 등록합니다.

프로버 호스트에서 다음을 설정하세요 `PROVER=on` 및 전체 runbook에 설명된 guest, 검증 메타데이터, ZisK 설정을 구성하세요. 키가 활성화된 후:

```sh
./rollup init
./rollup up
./rollup check
```

다음이 `서비스 프로버` 및 `검증 키` 항목이 통과하는지 확인하세요. 프로버는 inbox 배치를 순서대로 처리합니다. 각 유효한 증명은 Solana 트랜잭션이 도착하자마자 최종이 되는 루트를 게시합니다.

## 첫 블록 만들기

back된 genesis 잔액이 없으면, 예치가 열릴 때까지 체인에는 트랜잭션을 보낼 가스가 없습니다. 예치에는 먼저 증명된 루트가 필요합니다. 기본값 `empty_block_interval_secs = 0` 은 유휴 체인에 블록이 없게 만들므로, 다음으로 설정하세요 `60` 미만 `[profile]` 에서 `chain.toml` 으로, 키가 활성화되고 프로버가 실행 중인 뒤에 설정하세요. 렌더링하고 재시작하세요:

```sh
./rollup init
./rollup up
./rollup check
```

첫 루트가 최종이 되면, 간격을 다시 `0` 로 되돌리고 `init` 및 `up` 를 다시 실행하세요. 정기적인 빈 블록을 원하지 않는 한 그렇습니다. Rome이 키를 등록하는 것을 기다리는 동안 이를 켜면 대기열이 쌓입니다. 모든 배치는 순서대로 증명되어야 합니다.

60초 빈 블록 간격과 60초 배치 종료를 사용하면, 체인은 분당 약 1개, 즉 하루 약 1,440개의 배치를 만듭니다. devnet에서는 증명된 루트 1개당 payer 비용이 약 **0.003 SOL**입니다: pending-account 렌트 약 0.002 SOL, 정산 수수료 0.001 SOL, 그리고 그 위에 트랜잭션 수수료가 추가됩니다. 이 주기는 inbox 게시 비용을 제외하고 하루 약 4.4 SOL입니다. 기본 설정에서는 pending-account 렌트가 잠긴 상태로 유지됩니다. 빈 블록을 끄면 유휴 체인은 어떤 배치도 봉인하지 않으며 게시 비용도 지불하지 않습니다.

예치금을 받으려면, 먼저 금고를 만들고, 지연 후 출금 설정을 활성화하고, 예치 대기열을 여세요. 해당 명령과 점검은 [예치와 출금](/ko/rome-zk-evm/deposits-and-withdrawals.md).


---

# 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/run-a-rollup.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.