> 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/releases.md). # Versões O que a v0.3.0 adiciona e como uma chain migra entre versões de prova ZisK suportadas. Esta seção documenta **Rome ZK EVM v0.3.0**. Use a source, a imagem do nó e o batch guest correspondentes da v0.3.0. O guest usa ZisK 1.3.1-alpha. A tag de release nomeia a árvore de código-fonte usada para a imagem. O `main` branch pode ter mudado desde a release. Os [registro completo de alterações da v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/CHANGELOG.md#v030) registra os comandos, correções e limites por trás da release. O [política de release do ZisK](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ZISK-RELEASES.md) descreve o registro on-chain e o processo de migração. ## Na v0.3.0 As chains de devnet agora podem receber depósitos e pagar saques a partir de seus próprios cofres de SOL embrulhado. A autoridade da chain pode abrir uma fila de depósitos, definir seus limites e taxas e alterá-los após uma ativação com atraso. O sequencer credita os depósitos finalizados da Solana em blocos EVM; o batcher comita o intervalo ordenado deles ao batch da inbox. A imagem do nó inclui um provador de saída. Com `EXITS=on`isso, ele monitora o portal de saída da chain, prova saques contra raízes finais da Solana e envia ele mesmo a liberação do cofre. Ele usa seu próprio pagador. Por padrão, um pequeno pagamento a um destinatário sem uma conta de token SOL embrulhado aguarda liberação manual. `./rollup check` reporta a configuração de saída, a saúde do serviço, saídas travadas e o saldo do exit-payer. As provas usam ZisK 1.3.1-alpha. O Settlement e o Veritas agora mantêm uma chave de verificação e uma raiz de recursão fixada por release do ZisK. A configuração do host do provador baixa e verifica os arquivos de chave desta release, verifica os binários da GPU e prepara os arquivos constantes usados pela agregação. A release também adiciona os formulários de issue de solicitação de chave de verificação e de relatório de bug. O guia da devnet vincula as transações do explorer da própria execução de Rome, do registro ao pagamento. Esta release ainda deixa abertos os antigos accounts de batch da inbox e de chunk. Os accounts de pending-root permanecem abertos por padrão; seu aluguel se acumula. Rome ainda não decidiu por quanto tempo os dados antigos de batch devem permanecer na Solana. ## As releases do ZisK pertencem à chave de cada cadeia Cada chain tem um registro de chave de verificação. Uma entrada contém `programVK`um layout de valores públicos, um slot de ativação e um número de esquema. Esse número nomeia a release do ZisK usada para construir o guest e a chave; a prova não escolhe sua release. O registro tem quatro slots de entrada. | Esquema | release do ZisK | status da v0.3.0 | | ------- | --------------- | -------------------------------------------- | | `1` | `1.2.0-alpha` | Retirada; suas provas são recusadas. | | `2` | `1.3.1-alpha` | Aberta; novas entradas e provas são aceitas. | O Settlement procura a entrada ativa correspondente ao `programVK`. A entrada seleciona a chave Veritas dessa release e a raiz de recursão fixada. Uma prova com a raiz errada é recusada antes das verificações de valores públicos e pairing. Uma release retirada não tem chave de verificação no build de produção. ## Migre uma chain para uma nova release Instale a nova toolchain do ZisK e as chaves de prova mantendo a instalação antiga disponível. Defina juntos a tag da source do rollup, a tag do guest e a release do ZisK, então execute `./rollup guest-build` para construir um novo guest e `programVK` para o mesmo genesis. O provador precisa da instalação, do guest e dos metadados de verificação correspondentes do ZisK. Envie à Rome o genesis da chain, a tag do guest, o hash do ELF e `programVK`. Rome reconstrói e verifica o guest e registra a nova chave com um slot de ativação futuro. Se a chain já tiver postado uma raiz, Rome também precisa do guest e da release anteriores. Verifique a nova entrada on-chain e o slot de ativação e, então, troque o provador quando esse slot chegar. Rome aposenta a entrada antiga após a troca. Uma entrada futura não pode verificar antes. A política de suporte de Rome mantém no máximo duas releases do ZisK abertas ao mesmo tempo. Uma release em encerramento não aceita novas entradas, mas as entradas existentes ainda podem verificar enquanto as chains migram. Quando Rome anuncia que uma release está sendo encerrada, as chains em devnet e testnet têm 30 dias para migrar. Essa janela é a política de suporte de Rome, não um timer on-chain. Rome pode aposentar entradas de uma vez por uma retirada de segurança. Uma release retirada não aceita nem novas entradas nem provas, então uma chain que ainda esteja na 1.2.0-alpha precisa de uma entrada ativa da 1.3.1-alpha antes de poder postar outra raiz. --- # 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/releases.md?ask=&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.