> 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/trust-model.md). # Modelo de confiança Quem pode alterar uma chain Rome ZK EVM na devnet e em que depositantes e saques precisam confiar. Os programas compartilhados v0.3.0 na devnet da Solana são atualizáveis. Uma raiz comprovada é final sob as regras que esses programas impõem quando ela é publicada. Operadores e usuários também devem levar em conta quem pode alterar essas regras, quem controla cada cadeia e quem pode interromper a publicação de dados. Leia o [modelo de confiança completo da devnet v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) para ver os poderes exatos de cada autoridade e as verificações nos programas atuais. ## Autoridades de programa e de registro da Rome A Rome detém a autoridade de atualização para os programas compartilhados de caixa de entrada, liquidação, Veritas e bridge. É uma autoridade de assinatura única na devnet. Uma atualização pode entrar em vigor sem período de aviso e pode alterar qualquer regra atual do programa. Trate isso como uma suposição de confiança da devnet ao depositar fundos. A Rome também detém a autoridade do registro de liquidação. Nos programas atuais, ela pode ativar ou desativar o registro sem permissão, alterar os depósitos de registro para novas cadeias, alterar as taxas de liquidação mesmo para uma cadeia existente sem um limite de protocolo, escolher o tesouro, alterar a deriva de timestamp permitida e alterar a janela global de recuperação. A janela de recuperação pode ser reduzida para cadeias registradas, mas não abaixo de 216.000 slots sob o programa atual. A autoridade de registro registra, aposenta e altera o slot de ativação das chaves de verificação de uma cadeia. Uma prova conta apenas em relação a uma chave ativa para essa cadeia. Portanto, essa autoridade pode alterar quais provas do convidado podem finalizar novas raízes ou deixar uma cadeia sem nenhuma chave utilizável. Uma nova entrada pode ficar ativa assim que sua transação de registro for confirmada. Raízes já finalizadas permanecem finais quando uma chave é aposentada. Sem atualizar os programas, as chaves da Rome não podem criar um cofre para uma cadeia cuja autoridade a Rome não detenha, alterar o mint desse cofre, escolher para onde vão os pagamentos dele ou sacar dele sem uma saída comprovada. A autoridade de atualização do programa pode alterar essas regras, então os usuários devem confiar que a Rome não fará tal atualização na devnet. ## Sua autoridade de cadeia Na `./rollup` configuração, o pagador da Solana também é a autoridade da cadeia. Ele assina a publicação e finalização de lotes da caixa de entrada, a publicação de raízes comprovadas e a configuração da cadeia. Ele pode encerrar contas elegíveis de lote, fragmento e raiz pendente para recuperar seu aluguel. Não há instrução para rotacionar essa autoridade, então perdê-la interrompe essas ações assinadas. O registro fixa o ID da cadeia, o genesis, o programa da caixa de entrada e a duração da janela de desafio. A autoridade não pode editar o genesis registrado. Ela escolhe um destinatário de taxas nesse genesis. Uma nova cadeia normalmente começa com saldos zero; qualquer saldo inicial declarado precisa de lastro correspondente em cofre antes que a Rome registre sua chave de verificação. A liquidação, por si só, não verifica esse lastro. A autoridade pode propor um portal de saída diferente, um programa de bridge, um limite de saque e um vínculo do publicador. Uma proposta torna-se ativa no mínimo uma janela de desafio da cadeia depois. Qualquer pessoa pode ativá-la após esse slot. Os usuários devem inspecionar a configuração de saída ativa antes de sacar. Após o primeiro lote comprovado, a autoridade pode criar uma fila de depósitos e escolher seu prazo de inclusão, limites por lote e por bloco, depósito mínimo, taxa e destinatário da taxa. As alterações também têm um slot de ativação atrasado. O programa atual restringe quais depósitos em espera um **finalizado** lote pode omitir. Ele não força o operador a produzir esse lote. ## No que um usuário confia Um depositante confia que o operador manterá o sequenciador em funcionamento, incluirá o crédito em fila em um lote, publicará o lote e provará sua raiz. O operador pode escolher a ordem das transações EVM e recusar transações; não há um canal geral de inclusão forçada para transações EVM. Um saldo de depósito pode aparecer no RPC da cadeia antes de sua raiz ser final no Solana. Um retirante precisa de uma raiz final cobrindo a mensagem de saída, de uma configuração de saída ativa e de wrapped SOL suficiente no cofre da cadeia. O operador pode atrasar essa raiz ao interromper lotes ou provas. Ele pode atrasar os pagamentos ao interromper o provador de saída ou deixar sem fundos o cofre ou o pagador de saída. Qualquer pessoa pode enviar uma prova de saída válida e liberar, então o provador de saída do operador não é o único caminho depois que os dados e a raiz final estão disponíveis. Sob os programas atuais, a liquidação vincula uma prova de saída ao portal configurado e a uma raiz final. Ela limita as saídas por janela de desafio e impede repetição. O bridge lê o destinatário do registro comprovado e verifica a conta de token associada do destinatário. Quem envia a liberação não pode redirecionar seu pagamento. Um cofre sem fundos suficientes não pode pagar, mesmo que a prova de saída seja válida. O depósito de registro de 5 SOL é um vínculo de registro da cadeia, não um lastro para os saldos dos usuários. Ele se torna reembolsável para a autoridade da cadeia após a primeira raiz final ou dez raízes publicadas. Se nenhuma raiz for publicada antes do fim da janela de recuperação, qualquer pessoa pode recuperar a cadeia e seu depósito não reembolsado vai para o tesouro. A janela da devnet em v0.3.0 é de 6.480.000 slots, cerca de 30 dias, contados a partir do registro. --- # 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/trust-model.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.