Introdução: Desde o declínio gradual de Solana e o lançamento de Token por OP, Layer2 e Rollup parecem ter se tornado os novos paraísos para inúmeros praticantes de Web3. À medida que o mercado baixista continua a se espalhar, o FTX está fora do jogo e o Multicoin sofre pesadas perdas, os concorrentes do Ethereum gradualmente desapareceram do estágio Web3 e perderam continuamente a confiança para competir com o ETH. Mais e mais pessoas começaram a considerar o Rollup como o núcleo de uma nova rodada de narrativa, e mais e mais projetos surgiram no L2 como cogumelos depois da chuva.
Mas tudo isso é uma "falsa prosperidade" ou uma "bolha que pode estourar a qualquer momento"? O Rollup e o L2 são realmente tão bons quanto a maioria das pessoas afirma? É realmente tão seguro quanto as pessoas pensam que é? Sem mencionar que muitos OP Rollups não possuem provas de fraude, quais são os riscos de segurança de **Rollups? **
Este artigo é inspirado no "Upgradeability of Ethereum L2s" lançado recentemente pela L2BEAT. Visando os riscos de confiança de comitê e assinatura múltipla por trás da atualização do Rollup (atualize imediatamente o contrato do Rollup, removendo os ativos do usuário) e a conversa antiquada sobre o Rollup antes, pense no Multichain não muito tempo atrás e fale sobre por que o L2 não é tão "bonito" quanto muitas pessoas pensam.
Breve descrição do princípio Rollup
Uma breve descrição do princípio de funcionamento do Rollup:
**Ethereum Rollup = um conjunto de contratos nos próprios nós da rede Layer1 + Layer2. **
O grupo de nós da rede da Camada 2 pode ser dividido em vários tipos de papéis, sendo o mais importante o sequenciador (Sequencer). Ele recebe as solicitações de transação que ocorrem na Camada2, determina sua ordem de execução e, em seguida, empacota a sequência da transação em um lote (Batch), que é enviado ao contrato do projeto Rollup na Camada1 (doravante referido coletivamente como contrato Rollup).
O nodo completo da Camada2 pode obter diretamente a sequência de transações do sequenciador, ou ler o lote de transações (Batch) enviado pelo sequenciador para a Camada1, mas esta última tem maior certeza final (inalterabilidade) que a anterior. Normalmente, quando um lote de transações é enviado para o Layer1 pelo sequenciador, a ordem do lote de transações não pode ser alterada (desde que não haja rollback de bloco no Ethereum, a sequência de transações do Rollup não será alterada).
Como a execução da transação mudará o estado do ledger da blockchain, além da ordem das transações, o nó completo da Camada 2 também precisa sincronizar o estado do ledger com o sequenciador, para garantir a consistência.
Portanto, o sequenciador não só precisa transmitir lotes de transações para o contrato Rollup da Camada1, mas também transmite os resultados da atualização de estado (Stateroot/State diff) após a execução da transação para a Camada1.
Não é difícil ver que L1 (Ethereum) na verdade atua como um quadro de avisos para nós L2, que é muito mais descentralizado, sem confiança e mais seguro do que a própria rede do L2. Para nós completos L2, desde que obtenham a sequência de transações Rollup em L1 + o Stateroot inicial, eles podem restaurar o ledger blockchain L2 e calcular o Stateroot mais recente. Se o Stateroot calculado pelo próprio full node L2 for inconsistente com o Stateroot publicado pelo sequenciador para L1, significa que o sequenciador possui fraude.
O caso hipotético mais intuitivo é: O sequenciador do L2 pode roubar recursos do usuário. Por exemplo, pode forjar algumas transações que não deveriam ter ocorrido (ps: transferir alguns Tokens do usuário L2 para o endereço do operador do sequenciador e depois transferir esses Tokens para o L1). Esse tipo de pergunta pode ser resumida a: O que fazer depois que o sequenciador publica dados de transação errados ou Stateroot errado? **
Para o risco de fraude do sequenciador, diferentes tipos de Rollup possuem diferentes contramedidas. O Rollup Otimista (Optimistic Rollup) permite que os full nodes L2 forneçam provas de fraude (Fraud Proof), comprovando que os dados liberados pelo sequenciador em L1 possuem erros. Por exemplo, a Arbitrum criou uma lista branca de nós, permitindo que os nós L2 na lista branca emitam provas de fraude.
Além disso, considerando que a maioria das trocas e partes de projetos privados de cross-chain bridge executarão nós completos L2, os erros podem ser encontrados imediatamente e a taxa de sucesso da maioria dos sequenciadores Rollup que roubam moedas é basicamente 0 (porque precisa ser sacado no final, ainda precisa ser concluído na troca, ou as moedas roubadas podem ser transferidas para L1 e depois encontrar outra saída).
(O agregador na figura é na verdade um sequenciador)
Mas para Otimismo sem prova de fraude, o sequenciador pode roubar moedas por meio do próprio contrato de ponte cruzada da Rollup. Por exemplo, o operador do sequenciador pode forjar instruções de transação, transferir ativos de outras pessoas em L2 para seu próprio endereço e, em seguida, transferir as moedas roubadas para L1 por meio do contrato de ponte integrado do Rollup. Como não há prova de fraude, o nó completo do OP não pode desafiar a transação errada, portanto, em teoria, o sequenciador do OP pode roubar os ativos do usuário em L2 (desde que realmente queira fazê-lo).
A solução para esse tipo de problema é "consenso social" (supervisionado pela opinião pública, como membros da comunidade e mídia social), ou **confiar no endosso de crédito oficial do OP. **
Curiosamente, uma exchange recentemente reduziu o atraso dos usuários de Arbitrum e Optimism para transferir moedas para a exchange (de 100 blocos L2 para 1 bloco L2), o que é realmente confiar que os sequenciadores de ARB e OP não farão mal** (por padrão, eles são servidores centralizados com endosso oficial)**.
Ao contrário do Rollup otimista, além de contar com nós completos L2, o ZK Rollup resolve o problema de fraude do sequenciador por meio da Prova de Validade (muitas vezes confundida com a Prova ZK). Na rede ZK Rollup existe um nó chamado Prover, que tem como função gerar comprovações de validade dos lotes de transações emitidos pelo sequenciador. Ao mesmo tempo, existe um contrato (geralmente chamado de Verificador) no L1 que verifica especificamente o certificado de validade. Desde que o lote da transação e o certificado correspondente ao Stateroot/State diff passem na verificação do contrato do Verificador, ele será finalizado (Finalizado). A ponte oficial do ZK Rollup só liberará as transações de saque verificadas pelo certificado de validade, que obviamente é muito mais confiável que o Otimismo.
Em teoria, a segurança do OP Rollup é garantida por nós completos L2 (pelo menos um nó honesto que pode emitir provas de fraude). A segurança do ZK Rollup é garantida pelo contrato do Verifier em L1 (a transação é finalmente confirmada pelo nó L1). Superficialmente, todos eles podem "herdar a segurança de L1" (com a ajuda de L1 para concluir a confirmação/liquidação final da transação), e os maximalistas do Ethereum até chamam isso de "equivalente à segurança de L1" (consistente com a finalidade dos resultados da transação de L1), mas a situação real não é o caso, ou está longe disso.
Esses pontos "clichês"
Em primeiro lugar, a velocidade de geração da prova de validade do ZK Rollup é extremamente lenta, o sequenciador pode executar milhares de transações em 1 segundo, mas pode levar várias horas no máximo para gerar a prova para essas milhares de transações. Mas este problema também é fácil de resolver.O principal ZKR basicamente divide a tarefa de geração de prova e a envia para diferentes nós do Prover para processamento paralelo para aumentar consideravelmente a velocidade de geração de prova.
Em segundo lugar, é necessário considerar o atraso dos nós L2 publicando dados em L1. Porque cada vez que o sequenciador ou Prover enviar dados para o L1, haverá um custo fixo (como se fosse consumido um container para cada embarque). A publicação frequente de dados em L1 não é rentável ou até mesmo uma perda, portanto, o sequenciador e o Provedor minimizarão a frequência de publicação de dados em L1 e, em seguida, empacotarão e liberarão uma grande quantidade de dados de uma só vez.
Em outras palavras, quando o número de usuários for insuficiente e o número de transações iniciadas for insuficiente, o sequenciador irá atrasar a liberação de dados para L1. Por exemplo, quando havia poucos usuários no ano passado, o Optimism enviava apenas um lote de transações para L1 a cada meia hora. Agora, como o número de usuários aumentou, esse problema foi efetivamente resolvido. Diferente do OP, a Starknet adotou um método de redução da frequência dos lançamentos de diferenças de estado para reduzir os custos de dados, o que torna o atraso de confirmação final da transação da Starknet estendido para 7 a 8 horas.
Além disso, a maioria dos ZK Rollups costuma "agregar muitas provas e enviá-las para L1 de uma só vez" para reduzir ainda mais os custos. Ou seja, o Provedor não enviará para L1 imediatamente após a geração de uma Prova, mas aguardará que várias Provas sejam geradas, agregue-as e depois envie para o contrato do Verificador de L1. (Na verdade, o processo de agregação de Provas é usar uma Prova para incluir as etapas de cálculo geradas pela verificação de várias Provas)
A consequência disso é que a frequência das liberações de Prova é ainda mais reduzida e o atraso do início da transação até a confirmação final é ainda mais prolongado.
De acordo com o explorador de blocos, **o atraso na confirmação da transação do Polygon ZKEVM é de cerca de 30 a 50 minutos, e o Starknet e o Zksync Era são de mais de 7 horas. ** Obviamente, isso é apenas "herdar parcialmente a segurança de L1", que está longe de ser a "segurança equivalente a L1" que os apoiadores do Ethereum dizem.
Claro, todos os problemas acima podem ser resolvidos pelo progresso tecnológico e serão realizados em um futuro próximo. Por exemplo, muitas partes do projeto estão desenvolvendo hardware de alto desempenho para reduzir o tempo de geração de provas de validade; Otimismo também promete lançar um sistema à prova de fraude em breve; A solução Danksharding da Ethereum reduzirá o custo de dados do Rollup em dezenas de vezes ou até mais, o que pode efetivamente resolver os problemas listados acima.
Difícil resolver o problema do "governo do homem"
À semelhança de projetos aplicacionais como o Defi, o funcionamento da rede Rollup depende dos respetivos contratos em L1, sendo estes contratos “atualizáveis”, o que significa que alguns códigos podem ser substituídos (a maioria dos Rollups utiliza contratos proxy), podendo ser executados de imediato sob autorização de multi-assinatura ou comité de segurança. Deixe-me falar sobre a conclusão primeiro: **Rollup pode alterar rapidamente o código do contrato em L1 por meio de uma assinatura múltipla ou comitê de segurança controlado por algumas pessoas e, em seguida, roubar ativos do usuário. **
Em primeiro lugar, "por que o contrato Rollup precisa ser atualizado" e "como é atualizado". O código do contrato no Ethereum não pode ser alterado após a implantação, mas o Rollup inevitavelmente apresenta vários bugs durante o processo de desenvolvimento, o que pode levar a resultados incorretos; ao mesmo tempo, o Rollup também está passando por iterações frequentes do produto e novas funções precisam ser adicionadas com frequência; em casos mais extremos, pode haver hackers atacando o contrato Rollup, portanto, o contrato Rollup precisa ser atualizado, o que geralmente é obtido por meio de contratos proxy.
O contrato proxy é, na verdade, um método comumente usado no desenvolvimento de contratos Ethereum, que consiste em separar os dados do contrato da lógica de negócios e armazená-los em diferentes contratos. Dados (variáveis de estado) são armazenados em contratos proxy e lógica de negócios (funções) são armazenados em contratos lógicos. O contrato de proxy (Proxy) confia o processo de execução da função ao contrato lógico (Implementation) por meio de delegatecall e, em seguida, retorna o resultado final ao chamador (Caller).
Para atualizar o contrato no modo proxy, você só precisa apontar o contrato proxy para o novo contrato lógico (reescrever o endereço do contrato lógico armazenado no contrato proxy). **A maioria dos projetos Rollup adotou esse método de atualização de contrato, que pode ser descrito como simples e rude. **
Não é difícil imaginar que O contrato do Rollup pode ser atualizado é realmente um grande trovão: se o contrato atualizado contiver código malicioso, como modificar as condições de liberação de retirada do contrato Bridge integrado do Rollup ou modificar as condições do contrato do Verificador para determinar a validade e provar a correção, o sequenciador pode roubar moedas (o princípio é mencionado anteriormente).
Mas o problema é que o contrato Rollup não pode ser atualizado, o motivo é muito claro. Em suma, a grande maioria do Rollup decidirá se deve atualizar o contrato Rollup por meio da governança DAO, comitê de segurança ou autorização de assinatura múltipla. Além disso, o bloqueio de tempo Timelock será usado para definir um período de janela de atraso para atualizações de contrato.
Considerando que a maioria das propostas DAO tem um processo de execução automatizado (implementado por meio de contratos on-chain), mesmo que o contrato seja atualizado, primeiro devem ser obtidos votos suficientes e, em seguida, a operação de atualização do contrato só será executada após o atraso especificado pelo Timelock (geralmente muitos dias). Se alguém quiser se envolver em atualizações maliciosas de contratos, precisará superar a governança DAO por meio de ataques de governança (como os ataques de governança que ocorreram no Tornado Cash), mas o custo de fazer isso é muito alto e eles devem primeiro obter Tokens suficientes, que não terão sucesso em circunstâncias normais. Mesmo que o ataque de governança seja bem-sucedido, devido ao bloqueio de tempo, os usuários terão tempo suficiente para retirar ativos do L2 e os funcionários **Rollup terão tempo suficiente para tomar medidas de emergência. **
Parece que os timelocks são a arma mágica contra atualizações maliciosas de contratos. Mas o problema é que as chamadas "medidas de emergência que os funcionários do Rollup podem tomar" estão, na verdade, contornando a governança do DAO e os bloqueios de tempo e atualizando imediatamente o contrato do Rollup por meio de assinatura múltipla ou autorização do comitê de segurança. Considerando que o Rollup mainstream atual hospeda bilhões de dólares em ativos de usuários, a "atualização imediata do contrato" autorizada pelo comitê de assinatura múltipla e segurança é a medida de emergência definitiva, mas também é a espada de Dâmocles pairando sobre as cabeças de todos os usuários.
Obviamente, trata-se de maximizar a confiança: você precisa confiar que os funcionários do Rollup não terão a ideia de roubar seus ativos. Se você considerar da perspectiva do Trustless (perspectiva de Nick Szabo), **todos os Rollups controlados por assinaturas múltiplas e comitês de segurança são inseguros. **Emin Gun Sirer, o fundador da Avalanche, Anatoly, o fundador da Solana, e Justin Bons, a famosa mancha solar, enfatizaram esse tipo de problema.
Quais Rolllups são manipulados por multisigs/committees?
De acordo com o relatório "Upgradeability of Ethereum L2s" divulgado pela conhecida instituição de pesquisa L2 L2 BEAT e pelo site de visualização de dados L2BEAT, **Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM e outros Rollups convencionais, todos têm assinaturas múltiplas ou contratos atualizáveis autorizados por comitês e podem contornar as restrições de bloqueio de tempo. **
Embora dYdX tenha um endereço EOA que pode ignorar o contrato de atualização de governança DAO, ele é limitado por um bloqueio de tempo (pelo menos 2 dias de atraso). Immutable X tem um atraso de atualização de contrato de 14 dias. Portanto, de acordo com L2BEAT, **dYdX e Immutable X são menos confiáveis do que outros Rollups convencionais que lançaram a rede principal. **
**Então, como reduzir o risco de confiança trazido pela assinatura múltipla e pelo comitê de segurança? **A resposta é realmente semelhante ao incidente Multichain: pode ser atribuído ao problema anti-bruxa. Deve-se garantir que os multisigs/comitês sejam controlados por várias entidades diferentes sem alto grau de sobreposição de interesses e baixo risco de conluio. No momento, parece que não há uma boa maneira, exceto aumentar a maturidade da governança descentralizada do DAO e convidar celebridades ou instituições famosas e respeitáveis para participar de assinaturas/comitês múltiplos. O cenário acima parece ter sido comum nas democracias do mundo real.
Claro, também é possível limitar o comportamento de atualização do contrato gerenciado por assinatura múltipla/comitê por meio de bloqueio de tempo, mas isso precisa ser ponderado contra muitos fatores, porque o objetivo da assinatura múltipla/comitê é lidar rapidamente com algumas situações de emergência; ao mesmo tempo, se a parte do projeto Rollup não tiver uma determinação firme sobre a questão da falta de confiança, esse problema não poderá ser resolvido.
Portanto, embora diferentes projetos de Rollup possam garantir a segurança dos ativos do usuário na maioria das vezes por meio de um design de mecanismo sofisticado, a probabilidade de um evento cisne negro no Rollup não é zero devido à existência de multi-assinaturas e comitês. Mesmo que a probabilidade de multi-sig e conluio de membros do comitê seja de apenas 1 em 10.000, considerando o valor dos ativos sob custódia L2 (suposto em 10 bilhões de dólares americanos), o risco de ativos de usuários L2 ainda é tão alto quanto 1 milhão de dólares americanos por dia. Remanescente do incidente Multichain, é realmente assustador.
Então, eu pessoalmente acho que, como Polynya disse antes, a maioria dos fundos no ecossistema Ethereum ainda tenderá a circular e travar em L1 em vez de L2, e o ecossistema Rollup não será capaz de capturar a maior parte do valor no ecossistema Ethereum a longo prazo. Para grandes investidores e baleias, a rede principal Ethereum é obviamente um lugar mais adequado e confiável para obter fundos do que L2. Portanto, muitas pessoas têm considerado "se a ascensão de L2 levará à deserção de L1", na verdade, eles já têm a resposta.
Como disse Keigo Higashino em seu livro, o coração humano é muito mais elusivo, mais difícil de entender, mais complicado e mais difícil de mudar do que as fórmulas matemáticas. Muitas coisas não podem ser resolvidas por meios puramente técnicos, mas qualquer fator que envolva a "natureza humana" sempre será o problema mais incontrolável, imprevisível e mais grave deste mundo. Aqui, por favor, tenhamos em mente a frase clássica na lápide de Kant:
"Duas coisas sempre cercaram minha mente, e quanto mais penso nelas, mais espanto e admiração elas evocam em mim: a lei moral interior e o céu estrelado acima.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
O maior risco de confiança do Rollup: o problema do "governo do homem" que não pode ser ignorado
Autor: Link, Geek Web3
Introdução: Desde o declínio gradual de Solana e o lançamento de Token por OP, Layer2 e Rollup parecem ter se tornado os novos paraísos para inúmeros praticantes de Web3. À medida que o mercado baixista continua a se espalhar, o FTX está fora do jogo e o Multicoin sofre pesadas perdas, os concorrentes do Ethereum gradualmente desapareceram do estágio Web3 e perderam continuamente a confiança para competir com o ETH. Mais e mais pessoas começaram a considerar o Rollup como o núcleo de uma nova rodada de narrativa, e mais e mais projetos surgiram no L2 como cogumelos depois da chuva.
Mas tudo isso é uma "falsa prosperidade" ou uma "bolha que pode estourar a qualquer momento"? O Rollup e o L2 são realmente tão bons quanto a maioria das pessoas afirma? É realmente tão seguro quanto as pessoas pensam que é? Sem mencionar que muitos OP Rollups não possuem provas de fraude, quais são os riscos de segurança de **Rollups? **
Este artigo é inspirado no "Upgradeability of Ethereum L2s" lançado recentemente pela L2BEAT. Visando os riscos de confiança de comitê e assinatura múltipla por trás da atualização do Rollup (atualize imediatamente o contrato do Rollup, removendo os ativos do usuário) e a conversa antiquada sobre o Rollup antes, pense no Multichain não muito tempo atrás e fale sobre por que o L2 não é tão "bonito" quanto muitas pessoas pensam.
Breve descrição do princípio Rollup
Uma breve descrição do princípio de funcionamento do Rollup:
**Ethereum Rollup = um conjunto de contratos nos próprios nós da rede Layer1 + Layer2. **
O grupo de nós da rede da Camada 2 pode ser dividido em vários tipos de papéis, sendo o mais importante o sequenciador (Sequencer). Ele recebe as solicitações de transação que ocorrem na Camada2, determina sua ordem de execução e, em seguida, empacota a sequência da transação em um lote (Batch), que é enviado ao contrato do projeto Rollup na Camada1 (doravante referido coletivamente como contrato Rollup).
O nodo completo da Camada2 pode obter diretamente a sequência de transações do sequenciador, ou ler o lote de transações (Batch) enviado pelo sequenciador para a Camada1, mas esta última tem maior certeza final (inalterabilidade) que a anterior. Normalmente, quando um lote de transações é enviado para o Layer1 pelo sequenciador, a ordem do lote de transações não pode ser alterada (desde que não haja rollback de bloco no Ethereum, a sequência de transações do Rollup não será alterada).
Como a execução da transação mudará o estado do ledger da blockchain, além da ordem das transações, o nó completo da Camada 2 também precisa sincronizar o estado do ledger com o sequenciador, para garantir a consistência.
Portanto, o sequenciador não só precisa transmitir lotes de transações para o contrato Rollup da Camada1, mas também transmite os resultados da atualização de estado (Stateroot/State diff) após a execução da transação para a Camada1.
Não é difícil ver que L1 (Ethereum) na verdade atua como um quadro de avisos para nós L2, que é muito mais descentralizado, sem confiança e mais seguro do que a própria rede do L2. Para nós completos L2, desde que obtenham a sequência de transações Rollup em L1 + o Stateroot inicial, eles podem restaurar o ledger blockchain L2 e calcular o Stateroot mais recente. Se o Stateroot calculado pelo próprio full node L2 for inconsistente com o Stateroot publicado pelo sequenciador para L1, significa que o sequenciador possui fraude.
O caso hipotético mais intuitivo é: O sequenciador do L2 pode roubar recursos do usuário. Por exemplo, pode forjar algumas transações que não deveriam ter ocorrido (ps: transferir alguns Tokens do usuário L2 para o endereço do operador do sequenciador e depois transferir esses Tokens para o L1). Esse tipo de pergunta pode ser resumida a: O que fazer depois que o sequenciador publica dados de transação errados ou Stateroot errado? **
Para o risco de fraude do sequenciador, diferentes tipos de Rollup possuem diferentes contramedidas. O Rollup Otimista (Optimistic Rollup) permite que os full nodes L2 forneçam provas de fraude (Fraud Proof), comprovando que os dados liberados pelo sequenciador em L1 possuem erros. Por exemplo, a Arbitrum criou uma lista branca de nós, permitindo que os nós L2 na lista branca emitam provas de fraude.
Além disso, considerando que a maioria das trocas e partes de projetos privados de cross-chain bridge executarão nós completos L2, os erros podem ser encontrados imediatamente e a taxa de sucesso da maioria dos sequenciadores Rollup que roubam moedas é basicamente 0 (porque precisa ser sacado no final, ainda precisa ser concluído na troca, ou as moedas roubadas podem ser transferidas para L1 e depois encontrar outra saída).
(O agregador na figura é na verdade um sequenciador)
Mas para Otimismo sem prova de fraude, o sequenciador pode roubar moedas por meio do próprio contrato de ponte cruzada da Rollup. Por exemplo, o operador do sequenciador pode forjar instruções de transação, transferir ativos de outras pessoas em L2 para seu próprio endereço e, em seguida, transferir as moedas roubadas para L1 por meio do contrato de ponte integrado do Rollup. Como não há prova de fraude, o nó completo do OP não pode desafiar a transação errada, portanto, em teoria, o sequenciador do OP pode roubar os ativos do usuário em L2 (desde que realmente queira fazê-lo).
A solução para esse tipo de problema é "consenso social" (supervisionado pela opinião pública, como membros da comunidade e mídia social), ou **confiar no endosso de crédito oficial do OP. **
Curiosamente, uma exchange recentemente reduziu o atraso dos usuários de Arbitrum e Optimism para transferir moedas para a exchange (de 100 blocos L2 para 1 bloco L2), o que é realmente confiar que os sequenciadores de ARB e OP não farão mal** (por padrão, eles são servidores centralizados com endosso oficial)**.
Ao contrário do Rollup otimista, além de contar com nós completos L2, o ZK Rollup resolve o problema de fraude do sequenciador por meio da Prova de Validade (muitas vezes confundida com a Prova ZK). Na rede ZK Rollup existe um nó chamado Prover, que tem como função gerar comprovações de validade dos lotes de transações emitidos pelo sequenciador. Ao mesmo tempo, existe um contrato (geralmente chamado de Verificador) no L1 que verifica especificamente o certificado de validade. Desde que o lote da transação e o certificado correspondente ao Stateroot/State diff passem na verificação do contrato do Verificador, ele será finalizado (Finalizado). A ponte oficial do ZK Rollup só liberará as transações de saque verificadas pelo certificado de validade, que obviamente é muito mais confiável que o Otimismo.
Em teoria, a segurança do OP Rollup é garantida por nós completos L2 (pelo menos um nó honesto que pode emitir provas de fraude). A segurança do ZK Rollup é garantida pelo contrato do Verifier em L1 (a transação é finalmente confirmada pelo nó L1). Superficialmente, todos eles podem "herdar a segurança de L1" (com a ajuda de L1 para concluir a confirmação/liquidação final da transação), e os maximalistas do Ethereum até chamam isso de "equivalente à segurança de L1" (consistente com a finalidade dos resultados da transação de L1), mas a situação real não é o caso, ou está longe disso.
Esses pontos "clichês"
Em primeiro lugar, a velocidade de geração da prova de validade do ZK Rollup é extremamente lenta, o sequenciador pode executar milhares de transações em 1 segundo, mas pode levar várias horas no máximo para gerar a prova para essas milhares de transações. Mas este problema também é fácil de resolver.O principal ZKR basicamente divide a tarefa de geração de prova e a envia para diferentes nós do Prover para processamento paralelo para aumentar consideravelmente a velocidade de geração de prova.
Em segundo lugar, é necessário considerar o atraso dos nós L2 publicando dados em L1. Porque cada vez que o sequenciador ou Prover enviar dados para o L1, haverá um custo fixo (como se fosse consumido um container para cada embarque). A publicação frequente de dados em L1 não é rentável ou até mesmo uma perda, portanto, o sequenciador e o Provedor minimizarão a frequência de publicação de dados em L1 e, em seguida, empacotarão e liberarão uma grande quantidade de dados de uma só vez.
Em outras palavras, quando o número de usuários for insuficiente e o número de transações iniciadas for insuficiente, o sequenciador irá atrasar a liberação de dados para L1. Por exemplo, quando havia poucos usuários no ano passado, o Optimism enviava apenas um lote de transações para L1 a cada meia hora. Agora, como o número de usuários aumentou, esse problema foi efetivamente resolvido. Diferente do OP, a Starknet adotou um método de redução da frequência dos lançamentos de diferenças de estado para reduzir os custos de dados, o que torna o atraso de confirmação final da transação da Starknet estendido para 7 a 8 horas.
Além disso, a maioria dos ZK Rollups costuma "agregar muitas provas e enviá-las para L1 de uma só vez" para reduzir ainda mais os custos. Ou seja, o Provedor não enviará para L1 imediatamente após a geração de uma Prova, mas aguardará que várias Provas sejam geradas, agregue-as e depois envie para o contrato do Verificador de L1. (Na verdade, o processo de agregação de Provas é usar uma Prova para incluir as etapas de cálculo geradas pela verificação de várias Provas)
A consequência disso é que a frequência das liberações de Prova é ainda mais reduzida e o atraso do início da transação até a confirmação final é ainda mais prolongado.
De acordo com o explorador de blocos, **o atraso na confirmação da transação do Polygon ZKEVM é de cerca de 30 a 50 minutos, e o Starknet e o Zksync Era são de mais de 7 horas. ** Obviamente, isso é apenas "herdar parcialmente a segurança de L1", que está longe de ser a "segurança equivalente a L1" que os apoiadores do Ethereum dizem.
Claro, todos os problemas acima podem ser resolvidos pelo progresso tecnológico e serão realizados em um futuro próximo. Por exemplo, muitas partes do projeto estão desenvolvendo hardware de alto desempenho para reduzir o tempo de geração de provas de validade; Otimismo também promete lançar um sistema à prova de fraude em breve; A solução Danksharding da Ethereum reduzirá o custo de dados do Rollup em dezenas de vezes ou até mais, o que pode efetivamente resolver os problemas listados acima.
Difícil resolver o problema do "governo do homem"
À semelhança de projetos aplicacionais como o Defi, o funcionamento da rede Rollup depende dos respetivos contratos em L1, sendo estes contratos “atualizáveis”, o que significa que alguns códigos podem ser substituídos (a maioria dos Rollups utiliza contratos proxy), podendo ser executados de imediato sob autorização de multi-assinatura ou comité de segurança. Deixe-me falar sobre a conclusão primeiro: **Rollup pode alterar rapidamente o código do contrato em L1 por meio de uma assinatura múltipla ou comitê de segurança controlado por algumas pessoas e, em seguida, roubar ativos do usuário. **
Em primeiro lugar, "por que o contrato Rollup precisa ser atualizado" e "como é atualizado". O código do contrato no Ethereum não pode ser alterado após a implantação, mas o Rollup inevitavelmente apresenta vários bugs durante o processo de desenvolvimento, o que pode levar a resultados incorretos; ao mesmo tempo, o Rollup também está passando por iterações frequentes do produto e novas funções precisam ser adicionadas com frequência; em casos mais extremos, pode haver hackers atacando o contrato Rollup, portanto, o contrato Rollup precisa ser atualizado, o que geralmente é obtido por meio de contratos proxy.
O contrato proxy é, na verdade, um método comumente usado no desenvolvimento de contratos Ethereum, que consiste em separar os dados do contrato da lógica de negócios e armazená-los em diferentes contratos. Dados (variáveis de estado) são armazenados em contratos proxy e lógica de negócios (funções) são armazenados em contratos lógicos. O contrato de proxy (Proxy) confia o processo de execução da função ao contrato lógico (Implementation) por meio de delegatecall e, em seguida, retorna o resultado final ao chamador (Caller).
Para atualizar o contrato no modo proxy, você só precisa apontar o contrato proxy para o novo contrato lógico (reescrever o endereço do contrato lógico armazenado no contrato proxy). **A maioria dos projetos Rollup adotou esse método de atualização de contrato, que pode ser descrito como simples e rude. **
Não é difícil imaginar que O contrato do Rollup pode ser atualizado é realmente um grande trovão: se o contrato atualizado contiver código malicioso, como modificar as condições de liberação de retirada do contrato Bridge integrado do Rollup ou modificar as condições do contrato do Verificador para determinar a validade e provar a correção, o sequenciador pode roubar moedas (o princípio é mencionado anteriormente).
Mas o problema é que o contrato Rollup não pode ser atualizado, o motivo é muito claro. Em suma, a grande maioria do Rollup decidirá se deve atualizar o contrato Rollup por meio da governança DAO, comitê de segurança ou autorização de assinatura múltipla. Além disso, o bloqueio de tempo Timelock será usado para definir um período de janela de atraso para atualizações de contrato.
Considerando que a maioria das propostas DAO tem um processo de execução automatizado (implementado por meio de contratos on-chain), mesmo que o contrato seja atualizado, primeiro devem ser obtidos votos suficientes e, em seguida, a operação de atualização do contrato só será executada após o atraso especificado pelo Timelock (geralmente muitos dias). Se alguém quiser se envolver em atualizações maliciosas de contratos, precisará superar a governança DAO por meio de ataques de governança (como os ataques de governança que ocorreram no Tornado Cash), mas o custo de fazer isso é muito alto e eles devem primeiro obter Tokens suficientes, que não terão sucesso em circunstâncias normais. Mesmo que o ataque de governança seja bem-sucedido, devido ao bloqueio de tempo, os usuários terão tempo suficiente para retirar ativos do L2 e os funcionários **Rollup terão tempo suficiente para tomar medidas de emergência. **
Parece que os timelocks são a arma mágica contra atualizações maliciosas de contratos. Mas o problema é que as chamadas "medidas de emergência que os funcionários do Rollup podem tomar" estão, na verdade, contornando a governança do DAO e os bloqueios de tempo e atualizando imediatamente o contrato do Rollup por meio de assinatura múltipla ou autorização do comitê de segurança. Considerando que o Rollup mainstream atual hospeda bilhões de dólares em ativos de usuários, a "atualização imediata do contrato" autorizada pelo comitê de assinatura múltipla e segurança é a medida de emergência definitiva, mas também é a espada de Dâmocles pairando sobre as cabeças de todos os usuários.
Obviamente, trata-se de maximizar a confiança: você precisa confiar que os funcionários do Rollup não terão a ideia de roubar seus ativos. Se você considerar da perspectiva do Trustless (perspectiva de Nick Szabo), **todos os Rollups controlados por assinaturas múltiplas e comitês de segurança são inseguros. **Emin Gun Sirer, o fundador da Avalanche, Anatoly, o fundador da Solana, e Justin Bons, a famosa mancha solar, enfatizaram esse tipo de problema.
Quais Rolllups são manipulados por multisigs/committees?
De acordo com o relatório "Upgradeability of Ethereum L2s" divulgado pela conhecida instituição de pesquisa L2 L2 BEAT e pelo site de visualização de dados L2BEAT, **Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM e outros Rollups convencionais, todos têm assinaturas múltiplas ou contratos atualizáveis autorizados por comitês e podem contornar as restrições de bloqueio de tempo. **
Embora dYdX tenha um endereço EOA que pode ignorar o contrato de atualização de governança DAO, ele é limitado por um bloqueio de tempo (pelo menos 2 dias de atraso). Immutable X tem um atraso de atualização de contrato de 14 dias. Portanto, de acordo com L2BEAT, **dYdX e Immutable X são menos confiáveis do que outros Rollups convencionais que lançaram a rede principal. **
**Então, como reduzir o risco de confiança trazido pela assinatura múltipla e pelo comitê de segurança? **A resposta é realmente semelhante ao incidente Multichain: pode ser atribuído ao problema anti-bruxa. Deve-se garantir que os multisigs/comitês sejam controlados por várias entidades diferentes sem alto grau de sobreposição de interesses e baixo risco de conluio. No momento, parece que não há uma boa maneira, exceto aumentar a maturidade da governança descentralizada do DAO e convidar celebridades ou instituições famosas e respeitáveis para participar de assinaturas/comitês múltiplos. O cenário acima parece ter sido comum nas democracias do mundo real.
Claro, também é possível limitar o comportamento de atualização do contrato gerenciado por assinatura múltipla/comitê por meio de bloqueio de tempo, mas isso precisa ser ponderado contra muitos fatores, porque o objetivo da assinatura múltipla/comitê é lidar rapidamente com algumas situações de emergência; ao mesmo tempo, se a parte do projeto Rollup não tiver uma determinação firme sobre a questão da falta de confiança, esse problema não poderá ser resolvido.
Portanto, embora diferentes projetos de Rollup possam garantir a segurança dos ativos do usuário na maioria das vezes por meio de um design de mecanismo sofisticado, a probabilidade de um evento cisne negro no Rollup não é zero devido à existência de multi-assinaturas e comitês. Mesmo que a probabilidade de multi-sig e conluio de membros do comitê seja de apenas 1 em 10.000, considerando o valor dos ativos sob custódia L2 (suposto em 10 bilhões de dólares americanos), o risco de ativos de usuários L2 ainda é tão alto quanto 1 milhão de dólares americanos por dia. Remanescente do incidente Multichain, é realmente assustador.
Então, eu pessoalmente acho que, como Polynya disse antes, a maioria dos fundos no ecossistema Ethereum ainda tenderá a circular e travar em L1 em vez de L2, e o ecossistema Rollup não será capaz de capturar a maior parte do valor no ecossistema Ethereum a longo prazo. Para grandes investidores e baleias, a rede principal Ethereum é obviamente um lugar mais adequado e confiável para obter fundos do que L2. Portanto, muitas pessoas têm considerado "se a ascensão de L2 levará à deserção de L1", na verdade, eles já têm a resposta.
Como disse Keigo Higashino em seu livro, o coração humano é muito mais elusivo, mais difícil de entender, mais complicado e mais difícil de mudar do que as fórmulas matemáticas. Muitas coisas não podem ser resolvidas por meios puramente técnicos, mas qualquer fator que envolva a "natureza humana" sempre será o problema mais incontrolável, imprevisível e mais grave deste mundo. Aqui, por favor, tenhamos em mente a frase clássica na lápide de Kant:
"Duas coisas sempre cercaram minha mente, e quanto mais penso nelas, mais espanto e admiração elas evocam em mim: a lei moral interior e o céu estrelado acima.