Ir para o conteúdo
Financial Context Wiki

ZK rollups

Guia de verificação de lotes, provas de validade, disponibilidade de dados, estados de liquidação, taxas, saques e riscos específicos de cada implantação ZK rollup.

Atualizado

Somente para fins educacionais; não constitui orientação de investimento, bridge ou segurança. Um ZK rollup é tão confiável quanto seu programa provado, entradas públicas, caminho de disponibilidade de dados, contratos, operadores, governança e cadeia de liquidação.

Resposta direta

Um ZK rollup, mais precisamente um rollup de validade, executa transações fora de uma cadeia de liquidação, agrupa-as em lotes e envia compromissos de dados, alegações de estado e provas de validade aos contratos dessa cadeia. O verificador confere as regras de transição codificadas sem reexecutar cada transação. Assim, os custos de publicação e verificação são distribuídos entre muitas transações.

A garantia é específica, não absoluta. Uma prova verificada sustenta apenas a alegação codificada pelo programa implantado e vinculada às entradas públicas. Sozinha, não prova que os dados são recuperáveis, o sequenciador está ativo ou é justo, o bloco está finalizado, a bridge é correta ou um upgrade é seguro. “ZK” também não significa privacidade: muitos rollups publicam transações ou diferenças de estado.

1
Executar

O provador executa um lote ou cálculo e registra a transição de estado resultante.

Como funciona

  1. Fixe a implantação: IDs das cadeias L1 e L2, contratos do rollup e da bridge, verificador e versão da chave, programa ou circuitos provados, formato do lote, modo DA, sequenciador, provador, administradores, poderes de pausa e bloco observado. O nome da stack não garante todas as implantações.
  2. Separe ordenação e prova. O sequenciador pode emitir recibo rápido e blocos L2 antes que compromisso ou prova chegue à L1. Registre o lote exato e diferencie ordenado, comprometido, provado, aceito, seguro na liquidação, finalizado e saque concluído.
  3. Reconstrua o lote. Obtenha transações, diferenças de estado, blob sidecars ou outra carga exigida; confira ordem e compromissos; derive raízes anterior e posterior, raiz de saques ou mensagens e demais entradas públicas. Prova vinculada à cadeia, lote ou raiz errada prova outra alegação.
  4. Verifique o caminho da prova. Confirme que a transação chamou o verificador previsto com prova, chave e entradas esperadas, teve sucesso, emitiu o evento correto e atualizou o slot certo. Quando possível, reproduza verificação e execução com software independente.
  5. Audite a disponibilidade separadamente. Blobs do Ethereum oferecem disponibilidade na janela do protocolo e compromissos, não recuperação permanente. Comitê externo ou camada DA alternativa adiciona hipóteses próprias. Prova válida não restaura dados ausentes necessários para reconstruir o estado ou sair.
  6. Rastreie depósitos e saques ponta a ponta. Concilie token e mensageiro canônicos, valor, destino, nonce, raiz de inclusão, prova, regra de finalidade e saldo executado. Uma bridge rápida antecipa liquidez com preço, rota e risco de contraparte próprios; não encurta o relógio canônico.
  7. Monitore atividade e controle. Meça filas de lotes e provas, inclusão forçada e rotas de saída, diversidade de provadores, upgrades, timelocks, guardiões e modos de emergência. Repita após mudanças de contrato, circuito, chave, modo DA ou protocolo.

Exemplos calculados

  • Compressão. Um lote didático contém 10,000 transactions; 1,200 KB de entrada bruta viram 300 KB. 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/transaction. Isso não mede solidez, crescimento de estado nem arquivamento.
  • Alocação de custos. Usuários pagam 3.0 ETH; dados L1 custam 1.4 ETH, verificação 0.4 ETH e execução L2 0.2 ETH. O resíduo é 3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH e a média 3.0 / 10,000 = 0.0003 ETH/transaction. Não é lucro líquido: exclui provas, hardware, falhas, bridges, capital e tributos.
  • Ciclo de vida. Recibo em minute 0, compromisso L1 em minute 12, prova aceita em minute 50, política de finalidade atendida em minute 64 e saque canônico em minute 70. Tempo sequencial: 12 + 38 + 14 + 6 = 70 minutes. Nenhum instante anterior equivale ao saque concluído.

Riscos

  • Cadeia, implantação, contrato, lote, raiz, verificador, chave ou circuito errados.
  • Programa provado incompleto ou incorreto, fielmente provado por sistema sólido.
  • Entradas públicas, separadores de domínio, mensagens ou parâmetros ausentes ou mal codificados.
  • Falhas no verificador, pré-compilado, bridge, mensageiro ou contrato de estado.
  • Material de configuração comprometido ou hipóteses criptográficas quebradas.
  • Censura, reordenação, equívoco, queda ou publicação tardia do sequenciador.
  • Queda, centralização, censura, falta de capacidade ou fila crescente do provador.
  • Transações, diferenças de estado ou blob sidecars indisponíveis, malformados ou sem arquivo.
  • Confundir compromisso ou assinatura de comitê com recuperação atual.
  • Reorganização L1 ou confiança prematura em liquidação insegura.
  • Upgrades privilegiados, timelocks curtos, troca, pausas ou desvio de emergência.
  • Inclusão forçada, recuperação ou saída ausentes, desativadas ou inutilizáveis.
  • Bugs da bridge canônica, token errado, replay, mensagem ou prova de saque falha.
  • Riscos de liquidez, preço, rota, insolvência e contraparte de bridges rápidas.
  • Estimativas sem dados L1, provas, bridge, congestionamento ou falhas.
  • Aplicar a um rollup compatibilidade EVM, finalidade, privacidade ou segurança de outro.

Erros comuns

  • Todo ZK rollup oculta valores, endereços e atividade dos aplicativos.
  • Prova válida garante dados disponíveis e reconstrução do estado.
  • Recibo do sequenciador equivale a prova aceita na L1 ou saque finalizado.
  • Provas eliminam riscos de sequenciador, provador, governança, upgrade e bridge.
  • O sistema mais barato ou rápido produz automaticamente o resultado mais seguro.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...