Ir para o conteúdo

Rollups

Como rollups executam transações, publicam dados e compromissos, verificam transições de estado, liquidam em uma camada base e introduzem riscos operacionais próprios.

Atualizado

Somente para fins educacionais; não constitui aconselhamento financeiro, de investimento, de ponte ou de segurança. As garantias de um rollup dependem dos contratos implantados, sistema de provas, disponibilidade de dados, permissões do operador, governança e camada base, e tudo isso pode mudar.

Resposta direta

Um rollup é um projeto de escalabilidade de blockchain que executa transações fora de uma camada base, usando essa camada para publicar dados ou compromissos definidos pelo protocolo e liquidar transições de estado contestadas ou comprovadas. Muitas transações compartilham o custo de dados e liquidação da camada base. Portanto, um rollup é mais que compressão de transações, e uma raiz de estado isolada não fornece os dados necessários para reconstruir a cadeia.

Rollups otimistas geralmente aceitam alegações de estado, a menos que uma contestação bem-sucedida por prova de falha demonstre que a transição era inválida. Rollups ZK enviam provas de validade verificadas pelo contrato de liquidação. Esses nomes descrevem como transições são aceitas, não uma garantia universal sobre descentralização do sequenciador, armazenamento, controle de atualizações, taxas ou tempo de saque.

Como funciona

  • Ordenar e executar. Um sequenciador ou outro mecanismo seleciona e ordena transações e calcula o estado resultante. O usuário pode receber um recibo rápido antes da confirmação na camada base.
  • Publicar dados. O sistema publica dados de entrada suficientes na camada base, geralmente como calldata ou blobs, ou usa outro projeto de disponibilidade. Ela determina se nós independentes podem reconstruir e verificar o estado.
  • Comprometer o estado. O rollup publica raízes de estado ou outros compromissos que o vinculam a um resultado de execução. O compromisso é compacto, mas não é o histórico subjacente de transações.
  • Verificar transições. O projeto otimista depende de uma janela de contestação e de um processo de provas de falha implantado; o ZK depende de uma prova de validade e de um verificador on-chain. Erros, permissões e disponibilidade do sistema de provas importam nos dois.
  • Liquidar e sacar. Os contratos da camada base determinam quando uma alegação ou prova é aceita e como mensagens e ativos são finalizados. Saques canônicos podem sofrer atrasos de prova, contestação ou finalidade; uma ponte rápida acrescenta um provedor de liquidez e risco de contraparte.
  • Atualizar e recuperar. Governança, conselhos de segurança, guardiões ou administradores podem pausar ou atualizar contratos. O timelock, a rota de escape e a inclusão forçada devem ser verificados na implantação específica, não inferidos pela categoria.

Exemplo

Suponha que um lote contenha 1,000 transações. Os usuários pagam juntos 0.8 ETH, os dados na camada base custam 0.5 ETH e a execução do rollup custa 0.2 ETH. O restante sem explicação é 0.8 - 0.5 - 0.2 = 0.1 ETH, ou 0.1 / 1,000 = 0.0001 ETH por transação antes da geração de provas, infraestrutura, lotes com falha, custo de capital e reembolsos. É uma conciliação de custos, não lucro do operador.

Antes de considerar o lote final, verifique se o recibo foi confirmado apenas pelo sequenciador, se dados e compromisso chegaram à camada base, se a janela de prova de falha terminou ou a prova de validade foi aceita e se a mensagem de saque se tornou executável separadamente.

Riscos

  • Um sequenciador centralizado pode censurar, reordenar ou interromper transações temporariamente.
  • Dados ausentes ou indisponíveis do lote podem impedir reconstrução e saídas independentes.
  • Programas de prova de falha, circuitos de validade, verificadores ou clientes podem conter erros.
  • Contestadores ou produtores de provas podem ficar off-line, ser censurados, não ter fundos ou ter permissões incorretas.
  • Congestionamento, reorganização ou falha da camada base pode atrasar publicação, prova e liquidação.
  • Chaves de atualização, guardiões ou governança podem mudar código, parâmetros ou comportamento da ponte.
  • Pontes canônicas e mapeamentos de tokens podem falhar mesmo com execução correta do rollup.
  • Taxas, tempos de prova e atrasos de saque variam por implantação e podem mudar após atualizações.

Equívocos comuns

  • Todos os rollups armazenam tudo permanentemente na camada base. Formatos de publicação e garantias de arquivo variam; blobs, por exemplo, não são armazenamento permanente.
  • Um recibo do sequenciador é liquidação final. Pode ser uma promessa inicial de ordenação, não um resultado liquidado na camada base.
  • ZK significa privacidade. Nos rollups ZK, provas de validade demonstram o cálculo correto; privacidade de transações é uma escolha separada.
  • Otimista significa ausência de verificação. A correção depende de dados reproduzíveis, um sistema operacional de provas de falha e participantes capazes de contestar alegações inválidas.
  • Taxas médias menores eliminam o risco operacional. A liquidação compartilhada pode reduzir custos, mas permanecem dependências de sequenciador, provas, governança, ponte e disponibilidade de dados.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...