Ir para o conteúdo
Financial Context Wiki

Optimistic rollups

Guia específico por implantação sobre recibos do sequenciador, dados de derivação em L1, heads unsafe/safe/finalized, jogos de fault proof, retiradas canônicas, governança e saídas rápidas.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Um optimistic rollup executa um fluxo ordenado de transações e publica dados de derivação e afirmações de estado definidos pelo protocolo, sem anexar uma prova de validade a cada lote. “Optimistic” significa que uma afirmação elegível pode avançar segundo as regras implantadas, a menos que uma disputa de fault proof bem-sucedida demonstre que ela está errada. Não significa que uma mensagem do sequenciador prove correção, nem que toda implementação tenha contestações sem permissão ou o mesmo prazo de retirada.

Os nós do rollup derivam blocos L2 de forma independente a partir de entradas L1 canônicas e da configuração exata do protocolo. Portanto, o caminho de segurança inclui disponibilidade de dados, derivação e execução corretas, um sistema de fault proof ativo e sólido, acesso e finalidade de L1, governança e contratos da ponte. Uma raiz de estado isolada não basta para reconstruir a cadeia ou contestar uma transição inválida.

1
Sequência

O sequenciador ordena transações L2 e publica dados de transação ou compromissos.

Como funciona

  1. Fixe a implantação: IDs das cadeias L1 e L2, configuração e fork do rollup, contratos de inbox e ponte, formato do lote e modo de DA, contratos de afirmação de estado e jogo de disputa, versão do portal, administradores, guardiões e bloco de observação. A documentação de um stack não comprova que todo recurso esteja ativo em uma cadeia específica.
  2. Classifique o estado observado. Um recibo do sequenciador ou bloco unsafe é um compromisso local e rápido de ordenação; um lote publicado em L1 pode sustentar um head derivado safe; a finalidade de L1 pode sustentar um head derivado finalized. Uma afirmação de estado ou output, uma disputa resolvida e uma retirada executável são objetos e relógios distintos.
  3. Reconstrua o pipeline de derivação de L1 para L2. Verifique depósitos e entradas sequenciadas, canais e lotes, origens L1, alterações de configuração e transições de estado usando dados L1 canônicos. Para dados respaldados por blobs, diferencie disponibilidade durante a janela do protocolo de recuperação histórica posterior.
  4. Mapeie vivacidade e controle. Separe sequenciador, batcher, proponente, contestador, relayer, guardião e autoridade de upgrade; verifique se há caminhos de inclusão forçada ou delayed inbox, seus atrasos e condições de pausa, e se usuários comuns dispõem de software funcional para acioná-los.
  5. Verifique o caminho de fault proof implantado. Registre o tipo de jogo respeitado, permissões de proposta e contestação, bonds, pré-estado absoluto, programa de prova e VM, oráculo de preimagem, profundidade da afirmação, relógios e extensões, regras de resolução, poderes de blacklist ou pausa e atraso de upgrade. Não transplante a mecânica do OP Stack para Arbitrum ou outro rollup.
  6. Rastreie retiradas e economia separadamente. Acompanhe iniciação em L2, prova em L1, dependência da afirmação ou do jogo, atrasos de maturidade e finalidade, nova prova, verificações do portal e execução em L1. Trate uma saída rápida como operação de liquidez ou crédito precificada e com contraparte própria, não como redução do relógio canônico de contestação.
  7. Reconcilie continuamente. Compare hashes de blocos unsafe, safe e finalized, transações de lote em L1, afirmações de estado, resultados de jogos, mensagens da ponte, recibos, contratos de tokens e saldos finais. Reabra a análise após reorganização L1 ou L2, lote ausente, disputa, pausa, upgrade de contrato ou migração de DA.

Exemplos resolvidos

  • Payload de derivação. Um lote contém 10,000 transações, 1,200 KB de entradas brutas do protocolo e 300 KB após compressão. A razão é 1,200 / 300 = 4.0x, a redução é 1 - 300 / 1,200 = 75% e a média decimal é 300,000 / 10,000 = 30 bytes/tx. Esses números descrevem apenas o payload codificado, não gas em L1, correção da execução, tamanho do estado ou garantias de arquivo.
  • Contribuição antes dos custos omitidos. Usuários pagam 2.4 ETH; a execução L2 medida custa 0.3 ETH; a DA em L1 custa 1.2 ETH. O residual é 2.4 - 0.3 - 1.2 = 0.9 ETH, ou 0.9 / 10,000 = 0.00009 ETH/tx. Não é lucro líquido porque omite infraestrutura do operador, execução L1, jogos de prova, reembolsos, capital, falhas e tributos.
  • Localização da disputa. Uma trilha didática de execução tem 2^20 = 1,048,576 passos. Um estreitamento binário ideal exige log2(2^20) = 20 escolhas para isolar um passo. Se cada rodada didática tivesse um máximo separado de 3-hour, um limite serial ingênuo seria 20 * 3 = 60 hours; protocolos reais usam seus próprios relógios de xadrez, concorrência, extensões e agenda de transações.
  • Relógios de retirada e liquidez rápida. Um lote didático chega a L1 após 10 minutes, uma afirmação reconhecida surge após mais 30 minutes, um período hipotético de contestação dura 7 days e o relay final leva 2 hours. O tempo sequencial é 10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes. Uma ponte de liquidez que antecipa 4.97 ETH contra uma afirmação de 5 ETH cobra 0.03 ETH, ou 0.03 / 5 = 0.6%, enquanto a afirmação canônica permanece sujeita aos relógios e riscos originais.

Riscos

  • L1, L2, IDs de cadeia, configuração ou contratos incorretos.
  • Tratar um recibo unsafe do sequenciador como safe ou final.
  • Equivocação, censura, reordenação ou indisponibilidade do sequenciador.
  • Publicação do lote em L1 atrasada, ausente, malformada ou inválida.
  • Dados de blob ou DA alternativa indisponíveis ou não arquivados.
  • Divergência de cliente de derivação, configuração ou fork.
  • Reorganização de L1 invalidando entradas antes consideradas safe.
  • Indisponibilidade do batcher, proponente de estado ou participante da prova.
  • Caminho de inclusão forçada ou delayed inbox ausente, pausado ou mal compreendido.
  • Fault proofs não implantados, inativos ou associados ao tipo de jogo errado.
  • Papéis de proponente ou contestador permissionados ou em allowlist.
  • Contestador offline, censurado, subcapitalizado ou fora do prazo.
  • Falha no programa de prova, VM, pré-estado absoluto, oráculo ou verificador.
  • Erro de relógio, extensão, posição da afirmação, bond ou contabilidade da resolução.
  • Intervenção de guardião, conselho de segurança, pausa ou blacklist.
  • Upgrade imediato, timelock curto ou chaves administrativas comprometidas.
  • Vulnerabilidade da ponte canônica, mensageiro, replay ou mapeamento de ativos.
  • Falha na prova, maturidade, nova prova, finalização ou relay da retirada.
  • Risco de liquidez, preço, roteamento, insolvência ou contraparte na saída rápida.
  • Confundir finalidade de L1, finalidade L2 derivada, resolução da afirmação e recebimento do ativo.

Equívocos comuns

  • Optimistic significa que os usuários confiam incondicionalmente no resultado exibido pelo sequenciador.
  • Publicar apenas uma raiz de estado fornece disponibilidade de dados e derivação independente.
  • Todo optimistic rollup tem fault proofs sem permissão ativos e um relógio universal de sete dias.
  • Um bloco L2 safe ou finalized significa que sua retirada de L2 para L1 já pode ser executada.
  • Uma ponte rápida encurta o período canônico de contestação ou carrega apenas risco do rollup.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...