> 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/how-it-works.md). # Como funciona Acompanhe um bloco EVM desde o envio de dados para a Solana, passando pela prova ZisK, até a liquidação final. Seu sequenciador aceita transações EVM por meio de JSON-RPC. Ele verifica a assinatura, o nonce, os fundos e o gás, depois executa as transações aceitas na ordem de chegada. Ele grava sub-blocos assinados e suas transações em um log ordenado e durável antes de retornar uma pré-confirmação. O sequenciador incorpora o reth para produzir os blocos da cadeia. Uma pré-confirmação informa o que o sequenciador aceitou e ordenou. Ela não é uma raiz final da Solana. O restante do caminho publica os dados e prova que executá-los produz o estado reivindicado. ``` Transação EVM -> sequenciador -> log ordenado -> agregador de lotes -> caixa de entrada da Solana Caixa de entrada da Solana -> derivar -> reth-verifier -> blocos + testemunhos blocos + testemunhos -> provador (guest de lote ZisK) -> prova + raiz prova + raiz -> liquidação na Solana (PostRootProved) -> raiz final ``` ## Dos blocos até um lote da caixa de entrada O agregador de lotes lê blocos consecutivos do log ordenado. O exemplo `chain.toml` encerra um lote em 60 blocos, ou 60 segundos após o primeiro bloco, o que vier primeiro. Ele comprime o lote em frames, publica os frames como chunks da caixa de entrada na Solana e depois finaliza o compromisso de Merkle do lote. O compromisso da caixa de entrada cobre a cadeia e os IDs do lote, o slot de abertura, a contagem de chunks, a raiz de Merkle dos chunks e o intervalo de depósitos do lote. Finalizar um lote da caixa de entrada significa que seus dados foram publicados. Isso não torna sua raiz de estado final. A autoridade da cadeia assina a finalização do lote. O agregador de lotes não pode pular um número de bloco. A liquidação também pega o próximo lote na ordem. É por isso que um lote travado ou abandonado bloqueia raízes posteriores. O agregador de lotes retoma um lote parcialmente escrito sob o mesmo número após uma reinicialização quando consegue reconstruí-lo. ## Derivar, verificar e provar `derivar` lê lotes finais da caixa de entrada da Solana. Ele reconstrói os blocos e aciona um `reth-verifier` separado para executá-los novamente. Esse nó fornece os testemunhos de execução de que o provador de lote precisa e as provas de estado de que o provador de saídas precisa. Ele executa a API de teste do reth, então deve permanecer fora da rede pública. O provador lê cada lote final da caixa de entrada, obtém blocos e testemunhos do nó verificador e executa o guest de lote da cadeia no ZisK. O guest verifica se os blocos correspondem aos dados da caixa de entrada e são executados corretamente. Ele registra os valores públicos do lote, incluindo a raiz de estado resultante. Seu genesis e o destinatário das taxas são compilados nesse guest, então cada cadeia tem seu próprio guest e `programVK`. O provador verifica a prova localmente e então envia `PostRootProved`. O programa de liquidação verifica a chave de verificação ativa registrada para esta cadeia e a versão do ZisK nomeada por essa chave. Ele também verifica os valores públicos da prova em relação ao ID da cadeia, intervalo de blocos, predecessor, compromisso da caixa de entrada e raiz reivindicada. Veritas é o verificador da Rome para provas ZisK PLONK. A liquidação vincula o código do verificador e o executa dentro de `PostRootProved`; ela não chama o programa Veritas implantado separadamente. Uma prova válida grava uma `Raiz` final e avança a cabeça de finalização na mesma transação da Solana. A raiz de genesis de uma cadeia sem permissão não é final por si só. Sua primeira raiz final precisa de um lote provado. ## Fundos cruzando a fronteira Um depósito começa na Solana. O programa da ponte move o token depositado do depositante para o cofre dessa cadeia e acrescenta um registro numerado de depósito. O sequenciador lê os depósitos finais da Solana e credita o endereço EVM nomeado em ordem. O agregador de lotes registra o intervalo de depósitos com o lote. O saldo aparece na cadeia quando seu bloco é selado, mas seu crédito só é final quando a raiz desse lote é provada na Solana. Uma retirada começa na cadeia em seu portal de saída. O portal registra uma mensagem e queima o ativo nativo. O provador de saída observa essa mensagem e obtém uma prova de armazenamento do Ethereum a partir do nó verificador contra uma raiz final. Ele verifica essa prova localmente e então envia `ProvarSaída` para a liquidação na Solana. A liquidação verifica o portal, a mensagem, a raiz final e o limite de saídas, e impede que a mesma saída seja provada duas vezes. Em seguida, o provador de saída envia a transação de liberação da ponte. A ponte consome a saída provada e paga o destinatário a partir do cofre dessa cadeia em uma única transação atômica. O destinatário vem do registro provado, então a pessoa que envia a liberação não pode alterá-lo. Leia a [arquitetura v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.md) completa para formatos de wire, limites dos componentes e as verificações em cada instrução. --- # 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/how-it-works.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.