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

# Execute um rollup

Registre e execute sua própria chain Rome ZK EVM na devnet da Solana com o rollup runner v0.3.0.

Os `./rollup` o runner inicia uma cadeia contra os programas compartilhados da devnet da Solana da Rome. Você executa o nó dele e paga os custos de Solana. Você não implanta os programas de liquidação sozinho. O registro é sem permissão, mas raízes comprovadas precisam de uma chave de verificação específica da cadeia registrada pela Rome.

Esta página usa **v0.3.0**. O [guia completo da devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) cobre todas as configurações, falhas e etapas de recuperação.

## Antes de começar

Use uma máquina Linux x86-64 com bash 4 ou mais recente, Git, Docker Engine 28 ou mais recente com Compose, curl, jq, openssl, a CLI da Solana e Python 3.11 ou mais recente. Você precisa de um endpoint RPC da devnet da Solana, um par de chaves pagador da Solana com fundos, que também é a autoridade da sua cadeia, e uma chave de assinatura do sequenciador. Mantenha ambos os arquivos privados e legíveis pelo usuário 999 do contêiner. O guia explica como criá-los.

Reserve cerca de **7 SOL na devnet** para o pagador. O registro bloqueia 5 SOL; `./rollup check` espera pelo menos 1 SOL restante para postagem e aluguel. O depósito se torna reembolsável após a primeira raiz final ou dez raízes postadas. Se a cadeia for recuperada antes disso, o depósito vai para o tesouro. A cadeia também precisa de um endereço de destinatário de taxa EVM que você controle.

Para liquidar raízes, você precisa de um host de prover com uma GPU NVIDIA com mais de 30 GB de memória. Uma placa de 24 GB é pequena demais para a etapa final da prova. [Host do prover](/pt-br/rome-zk-evm/prover-host.md) fornece o orçamento de RAM e disco. O nó pode ser executado e publicar lotes antes de o prover estar pronto, mas nenhuma de suas raízes será final.

## Inicie o nó

Clone a release e trabalhe a partir do diretório rollup dela:

```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
```

Defina o RPC da Solana, os locais dos assinantes e `ROME_ZK_TAG=v0.3.0` em `.env`. Mantenha `PROGRAMS_JSON=programs.devnet.json`. Defina `ROME_ZK_GUEST_TAG=v0.3.0` e `ZISK_RELEASE=1.3.1-alpha` para a compilação posterior do guest. Mantenha o RPC vinculado ao loopback para uma primeira execução local. Deixe `PROVER` indefinido até que o guest e sua chave estejam prontos.

Defina `genesis.fee_recipient` em `chain.toml` para o seu endereço EVM. Não escolha um chain ID. A liquidação deriva um a partir do pagador e da sua contagem de registros; `init` lê isso antes de enviar qualquer coisa. Cerca de metade de todos os IDs é grande demais para o MetaMask. Se o seu for um deles, `init` para com `ChainIdNotWalletSafe`; crie uma nova chave do pagador, aponte `PAYER_KEYPAIR_PATH` para ela e execute `init` novamente.

Uma nova cadeia começa com saldos zero. Se você declarar um saldo respaldado para obter gás antes de as entradas serem abertas, bloqueie a mesma quantia de SOL embrulhado no cofre da cadeia antes de solicitar a chave de verificação.

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

`init` gera o genesis e a configuração do serviço. `register --confirm` bloqueia o depósito de 5 SOL e cria o cursor do lote. `up` inicia o nó sequencer, o batcher, o derive e o verificador. `check` nomeia qualquer serviço ausente e depois compara o chain ID, as cabeças, o progresso do batcher, a caixa de entrada e as raízes. Execute-o novamente depois que os lotes tiverem tempo de fechar; a primeira verificação de progresso do lote só registra uma amostra.

Sem um prover, o sequencer fornece RPC, o batcher publica os dados da transação na caixa de entrada, e o derive reconstrói a cadeia. Um lote da caixa de entrada não é uma raiz final de liquidação. Até mesmo a raiz do genesis espera por uma prova.

## Passe de lotes para raízes finais

Compile o guest para o genesis da sua chain:

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

A compilação usa o guest v0.3.0 e o ZisK 1.3.1-alpha. Ela produz o programa guest da chain e os metadados da chave de verificação. Calcular `programVK` precisa das chaves de prova do ZisK e de cerca de 36 GB de RAM. Registrar a cadeia não registra uma chave de verificação. Envie a [solicitação da chave de verificação](/pt-br/rome-zk-evm/verification-key.md) após a compilação. A Rome verifica seu genesis e seu guest e então registra a chave com um slot de ativação.

No host do prover, defina `PROVER=on` e o guest, os metadados de verificação e as configurações do ZisK descritos no runbook completo. Depois que a chave estiver ativa:

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

Verifique se o `serviço do prover` e `chave de verificação` itens passam. O prover processa os lotes da inbox em ordem. Cada prova válida publica uma raiz que se torna final assim que a transação na Solana é confirmada.

## Faça o primeiro bloco

Sem um saldo genesis respaldado, a cadeia não tem gás para uma transação até que as entradas sejam abertas. As entradas precisam de uma primeira raiz provada. O padrão `empty_block_interval_secs = 0` deixa uma cadeia ociosa sem blocos, então defina como `60` menor que `[profile]` em `chain.toml` depois que a chave estiver ativa e o prover estiver em execução. Gere e reinicie:

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

Quando a primeira raiz estiver final, volte a definir o intervalo para `0` e execute novamente `init` e `up` a menos que você queira blocos vazios regulares. Ativá-los enquanto espera a Rome registrar a chave cria uma fila acumulada. Todo lote precisa ser provado em ordem.

Com um intervalo de bloco vazio de 60 segundos e fechamento de lote de 60 segundos, a cadeia faz cerca de um lote por minuto, ou cerca de 1.440 por dia. Na devnet, uma raiz provada custou ao pagador cerca de **0.003 SOL**: cerca de 0.002 SOL em aluguel de conta pendente, a taxa de liquidação de 0.001 SOL e, além disso, uma taxa de transação. Esse ritmo equivale a cerca de 4.4 SOL por dia antes dos custos de postagem na inbox. O aluguel de conta pendente permanece bloqueado com as configurações padrão. Com blocos vazios desativados, uma cadeia ociosa não fecha lotes nem paga custos de postagem.

Para aceitar depósitos, crie primeiro o cofre, ative a configuração de saída após o atraso dela e abra uma fila de depósitos. Esses comandos e as verificações estão em [Depósitos e saques](/pt-br/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/pt-br/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.