> 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/zh/rome-zk-evm/run-a-rollup.md).

# 运行一个 rollup

使用 v0.3.0 rollup runner 在 Solana devnet 上注册并运行你自己的 Rome ZK EVM 链。

上面的 `./rollup` runner 会基于 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) 涵盖所有设置、故障和恢复步骤。

## 开始前

请使用一台 x86-64 Linux 机器，安装 bash 4 或更高版本、Git、Docker Engine 28 或更高版本（含 Compose）、curl、jq、openssl、Solana CLI 和 Python 3.11 或更高版本。你需要一个 Solana devnet RPC 端点、一个已注资的 Solana payer 密钥对（同时也是你的链权限主体）以及一个排序器签名密钥。请将这两个文件保密，并确保容器用户 999 可读。指南会说明如何创建它们。

预算约 **devnet 上的 7 SOL** 用于 payer。注册会锁定 5 SOL； `./rollup check` 并要求至少剩余 1 SOL 用于发布和租金。存款会在第一个最终根或累计发布十个根后变为可退还。若在此之前收回该链，押金将归入国库。该链还需要一个你可控制的 EVM 费用接收地址。

要结算根，你需要一台证明主机，配备一块内存超过 30 GB 的 NVIDIA GPU。24 GB 显存的卡对于最终证明步骤来说太小。 [证明主机](/zh/rome-zk-evm/prover-host.md) 提供内存和磁盘预算。节点可以在证明器准备好之前运行并发布批次，但其根都不会是最终根。

## 启动节点

克隆该发行版，并在其 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 绑定在回环地址上。保持 `PROVER` 未设置，直到 guest 及其密钥就绪。

设置 `genesis.fee_recipient` 从 `chain.toml` 改为你的 EVM 地址。不要自行选择链 ID。结算会根据 payer 及其注册次数推导出一个链 ID； `init` 会在发送任何内容前读取它。大约一半的 ID 对 MetaMask 来说都太大了。如果你的 ID 属于这种情况， `init` 会停止并显示 `ChainIdNotWalletSafe`；请创建一个新的 payer 密钥，将 `PAYER_KEYPAIR_PATH` 指向它，然后运行 `init` 再次运行。

新链的初始余额为零。如果你在存款开放前声明一笔有资产支持的余额以获取 gas，则在申请验证密钥之前，先在该链的金库中锁定同等数量的 wrapped SOL。

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

`init` 会生成 genesis 和服务配置。 `register --confirm` 会锁定 5 SOL 押金并创建批次游标。 `up` 会启动 sequencer、batcher、derive 和 verifier 节点。 `check` 会指出任何缺失的服务，然后比较链 ID、heads、batcher 的进度、inbox 和 roots。待批次有时间关闭后再运行一次；它的第一次批次进度检查仅会记录一个样本。

没有证明器时，sequencer 提供 RPC，batcher 将交易数据发布到 inbox，而 derive 重建链。inbox 中的批次并不是最终结算根。即使是 genesis 根也需要等待证明。

## 从批次过渡到最终根

为你的链的 genesis 构建 guest：

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

该构建使用 v0.3.0 guest 和 ZisK 1.3.1-alpha。它会生成该链的 guest 程序和验证密钥元数据。计算 `programVK` 需要 ZisK 证明密钥以及大约 36 GB 内存。注册链不会注册验证密钥。发送 [验证密钥请求](/zh/rome-zk-evm/verification-key.md) 在构建完成后发送。Rome 会检查你的 genesis 和 guest，然后为该密钥注册一个激活槽位。

在证明主机上，设置 `PROVER=on` 以及完整运行手册中描述的 guest、验证元数据和 ZisK 设置。密钥激活后：

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

检查 `service prover` 和 `验证密钥` 各项检查是否通过。证明器会按顺序处理 inbox 批次。每个有效证明都会发布一个根，该根在其 Solana 交易落地后立即成为最终根。

## 生成第一个区块

如果没有有资产支持的 genesis 余额，在存款开放之前，该链没有用于交易的 gas。存款需要第一个已证明根。默认的 `empty_block_interval_secs = 0` 会使空闲链没有区块，因此将其设为 `60` 小于 `[profile]` 从 `chain.toml` ，待密钥激活且证明器运行后再执行。渲染并重启：

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

一旦第一个根成为最终根，就将该间隔恢复为 `0` 并重新运行 `init` 和 `up` ，除非你希望定期产生空区块。在等待 Rome 注册密钥时启用它们会造成积压。每个批次都必须按顺序证明。

在空区块间隔为 60 秒、批次关闭间隔为 60 秒的情况下，该链大约每分钟生成一个批次，即每天约 1,440 个。在 devnet 上，一个已证明的根使 payer 的花费约为 **0.003 SOL**：其中约 0.002 SOL 为待处理账户租金，0.001 SOL 为结算费用，另外还要加上交易费。按这个节奏计算，在不计 inbox 发布成本前，每天约为 4.4 SOL。使用默认设置时，待处理账户租金会保持锁定。关闭空区块后，空闲链不会封存任何批次，也不会产生发布成本。

要接受存款，接下来需要创建金库，在其延迟结束后激活退出配置，并打开存款队列。这些命令和检查位于 [存款和提现](/zh/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/zh/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.