Blast to Layer 2 multi-assinatura backdoor: o que é mais importante, tecnologia ou consenso social

金色财经_

Autor: Fausto, geek web3

Introdução: O subtexto de Blast em face de Layer2 ortodoxos como Polygon zkEVM pode ser "Generais principescos, você preferiria ter um tipo de?"Como todos não estão confiando o suficiente, a essência de **** é confiar no consenso social para garantir a segurança, então por que se preocupar em criticar a concentração de Blast’s Layer2 não é alta o suficiente, “por que é muito ansioso”?

É certo que a dependência da Blast em 3/5 multisig para controlar endereços de depósito tem sido amplamente criticada, mas a maioria dos Layer 2s também depende de multisig para gerenciar contratos, e a Optimism até usou apenas um endereço EOA para controlar privilégios de escalonamento de contratos. Em uma época em que a Camada 2 convencional quase todas têm riscos de segurança, como multiassinatura, criticar a Blast por não ser segura o suficiente é mais como o “desdém” da elite técnica por um projeto de mineração de ouro.

Mas deixando de lado os dois méritos acima, o significado da existência do blockchain é mais para resolver o problema da opacidade da informação no consenso social/governança democrática, e ao defender a supremacia da tecnologia, devemos admitir que o consenso social em si é mais importante do que a tecnologia, porque é a base que garante o funcionamento eficaz de todos os projetos Web3. Em última análise, a tecnologia está a serviço do consenso social, e projetos que não podem ser reconhecidos pela maioria das pessoas, por mais superior que seja a tecnologia, são essencialmente apenas um lindo apêndice.

Texto: Recentemente, o novo projeto Blast lançado pelo fundador do Blur tornou-se popular em toda a rede, este protocolo de “interesse de ativos” sob a bandeira da Camada 2 criou um endereço de depósito na cadeia ETH, e depois que os usuários depositarem fundos no endereço Blast, esses fundos serão usados para staking nativo da rede ETH, colocando-os no MakerDAO para ganhar juros, etc., e os lucros serão devolvidos aos usuários.

Contando com a aura do próprio fundador e a jogabilidade atraente, a Blast recebeu US$ 20 milhões em financiamento de investidores liderados pela Paradigm, e também atraiu a participação de inúmeros investidores de varejo. **Menos de 5 dias após seu lançamento, os endereços de recarga Blast atraíram mais de US $ 400 milhões em TVL. Não é exagero dizer que o BLast é como um medicamento forte em um longo mercado em baixa, que instantaneamente despertou o frenesi das pessoas.

No entanto, embora a Blast tenha alcançado um sucesso faseado, também atraiu dúvidas de muitos especialistas. Por exemplo, os engenheiros da L2BEAT e da Polygon disseram que o Blast atual é apenas um contrato de depósito implantado no Ethereum, e este contrato pode ser atualizado sob o controle de 3/5 multisig, ou seja, a lógica de código do contrato pode ser reescrita, e o Rug ainda pode ser Rug. Ao mesmo tempo, a Blast apenas afirma implementar uma estrutura de rollup, mas agora é apenas um shell vazio, e mesmo a função de retirada não será lançada até fevereiro do próximo ano.

E Blast também é insuportável para mostrar fraqueza, **A grande maioria dos Rollups dependem de um conjunto de contratos de gerenciamento de várias assinaturas por trás deles para atualizar suas permissões, e outros Layer2 acusa “Blast com multi-assinatura” é apenas 50 passos e 100 passos. **

Layer2 multisig é um problema de longa data

Na verdade, a assinatura múltipla de contratos de camada 2 tem sido um problema de longa data. Já em julho deste ano, a L2BEAT conduziu uma investigação especial sobre a possibilidade de atualização do contrato Rollup, e o chamado “atualizável” é alterar o endereço lógico do contrato apontado pelo contrato de procuração para obter o efeito de alterar a lógica do contrato. **Se o novo contrato contiver lógica maliciosa, a Camada 2 pode roubar os ativos do usuário.

(图源:WTF Academy)

De acordo com os dados do L2BEAT, no momento, os principais rollups como Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet e Polygon ZKEVM adotaram contratos de atualização autorizados com várias assinaturas, que podem ser atualizados imediatamente ignorando o limite de timelock. **

Surpreendentemente, o Optimism costumava usar apenas um endereço EOA para gerenciar a atualização do contrato, e até mesmo o multisig só foi adicionado em outubro deste ano. Quanto ao **Polygon zkEVM, que atacou o Blast, ele também pode realizar uma “aquisição de emergência” do contrato do Rollup sob a autorização de 6/8 multi-assinatura, e mudar a Camada 2 de governança de contrato para “governança humana nua”. Curiosamente, isso também foi mencionado pelo engenheiro da Polygon que criticou Blast acima, mas de uma maneira vaga.

Então, qual é o significado da existência desse “modo de emergência”?**Por que a maioria dos rollups tem que deixar um botão de pânico ou backdoor?**De acordo com a declaração anterior de Vitalik, os Rollups precisam atualizar frequentemente os contratos implantados no ETH durante o processo de iteração, e é difícil iterar de forma eficiente sem introduzir meios atualizáveis, como contratos de proxy.

Além disso, os contratos inteligentes que hospedam um grande número de ativos podem ter bugs que não são facilmente detetados, e é inevitável que a equipe de desenvolvimento da Camada 2 seja negligente e, se algumas vulnerabilidades forem exploradas por hackers, isso pode levar ao roubo de grandes quantidades de ativos. Portanto, seja um protocolo de Camada 2 ou DeFi, um botão de pânico é frequentemente configurado e os “membros do comitê” intervêm quando necessário para evitar que alguns eventos viciosos aconteçam. **

É claro que os comitês de Camada 2 muitas vezes podem ignorar restrições de bloqueio de tempo e atualizar imediatamente o código do contrato, mas, de um certo ponto de vista, eles parecem ser mais tabu do que hackers e outros fatores externos. Em outras palavras, em qualquer caso, é difícil para um contrato inteligente que hospeda uma enorme quantidade de ativos ser isento de um certo grau de “presunção de confiança”, ou seja, a suposição de que o controlador multisig por trás do contrato não faz mal. A menos que o contrato seja projetado para não ser atualizável e não haja bugs que possam ameaçar a segurança dos ativos do usuário.

A realidade é que os principais Tier 2s permitem que seus próprios comitês atualizem os contratos imediatamente, ou introduzem restrições de bloqueio de tempo mais curtas (por exemplo, qualquer pessoa que queira atualizar o contrato dYdX tem um atraso de pelo menos 48 horas). Se for descoberto que o comitê pretende adicionar lógica maliciosa de roubo de ativos à nova versão do código do contrato, o usuário teoricamente terá tempo suficiente para reagir e retirar urgentemente os ativos da Camada 1. **

(Um bloqueio de tempo é um atraso que permite executar determinadas operações)

Mas o cerne do problema é que muitos Layer 2s nem sequer têm uma função de retirada forçada que pode ignorar o sequenciador Sequencer, então o oficial da Camada 2 pode fazer o mal permitindo que o sequenciador rejeite o pedido de retirada de todos primeiro e, em seguida, transfira os ativos do usuário para a conta L2 controlada pelo oficial da Camada 2. Depois disso, o funcionário atualizará o contrato de Rollup de acordo com suas próprias necessidades e, quando o atraso de bloqueio terminar, todos os ativos do usuário poderão ser transferidos para a cadeia ETH.

Claro, a situação real pode ser pior do que eu disse, porque a maioria dos rollups pode atualizar contratos sem bloqueios de tempo, o que significa que eles podem completar centenas de milhões de dólares de tapetes quase instantaneamente.

Uma Camada 2 verdadeiramente sem confiança deve tornar o atraso de atualização do contrato maior do que o atraso de retirada forçada

Na verdade, para resolver o problema de segurança/confiança da Camada 2, as seguintes coisas precisam ser feitas:

Ao configurar uma saída de retirada resistente à censura na Camada 1, os usuários podem transferir ativos diretamente da Camada 2 para a cadeia ETH sem a permissão do sequenciador. O atraso da retirada forçada não deve ser muito longo, de modo a garantir que os ativos do usuário possam ser rapidamente retirados da L2;

Qualquer pessoa que queira atualizar um contrato de Camada 2 deve estar sujeita a um limite de atraso de bloqueio de tempo, **a atualização do contrato deve entrar em vigor depois da retirada obrigatória. **Por exemplo, se houver um atraso de pelo menos 48 horas para a atualização do contrato do dYdX, então o atraso para o modo pod de retirada/fuga obrigatório deve ser reduzido para 48 horas. Desta forma, depois que o usuário descobre que a parte do projeto dYdX quer dopar a nova versão do contrato com código malicioso, ele pode retirar os ativos da Camada 2 para a Camada 1 antes que o contrato seja atualizado. **

Atualmente, a grande maioria dos rollups que lançaram o mecanismo de retirada/fuga forçada não satisfazem as condições acima. Por exemplo, o pod de retirada/fuga forçada do dYdX tem um atraso máximo de 7 dias, mas o atraso de atualização do contrato do comitê do dYdX é de apenas 48 horas, o que significa que o comitê ** pode concluir a implantação de novos contratos antes que a retirada forçada do usuário entre em vigor e roubar os ativos antes que o usuário escape. **

Deste ponto de vista, exceto para Fuel, ZKSpace e Degate, outros rollups não podem garantir que a retirada forçada do usuário será processada antes que o contrato seja atualizado, e há um alto grau de presunção de confiança.

Muitos projetos que adotam o esquema de Validação (DA é implementado off-chain no Ethereum) têm um longo atraso de atualização de contrato (por exemplo, 8 dias ou mais),** mas o Validium geralmente depende de nós de DAC off-chain para publicar os dados mais recentes, e os DACs podem lançar ataques de retenção de dados que invalidam retiradas forçadas, portanto, não atendem ao modelo de segurança discutido acima. **

Neste ponto, parece claro e conciso concluir que nenhuma das soluções de Camada 2, com exceção de Fuel, ZKSpace e DeGate, são confiáveis. Os usuários confiam no projeto de Camada 2 ou no comitê de segurança criado por ele para não fazer o mal, ou confiam nos nós do DAC fora da cadeia para não conluio, ou confiam no sequenciador para não revisar sua transação (rejeitar sua solicitação). Existem apenas 3 camadas 2 que realmente atendem aos requisitos de segurança, resistência à censura e falta de confiança.

A segurança não é alcançada apenas pela tecnologia, mas deve introduzir o consenso social

De fato, o tema que estamos falando hoje não é novo, e a essência da Camada 2 apontada neste artigo depende da credibilidade do projeto que vem sendo apontada por inúmeras pessoas há muito tempo. Por exemplo, a Avalanche e os fundadores da Solana atacaram isso, mas o problema é que essas suposições de confiança que existem na Camada 2 também existem na Camada 1 e até mesmo em todos os projetos de blockchain. **

Por exemplo, precisamos assumir que os nós validadores que respondem por 2/3 do peso da participação na rede Solana não conluiam, e precisamos assumir que os dois principais pools de mineração, que respondem pela maioria do poder de hash do Bitcoin, não unem forças para lançar um ataque de 51% para reverter a cadeia mais longa. Embora essas suposições sejam difíceis de quebrar, “difícil” não significa “não”.

Uma vez que a cadeia pública tradicional da Camada 1 tem um comportamento maligno que causa danos a um grande número de ativos do usuário, ela muitas vezes abandonará a cadeia problemática e bifurcará uma nova cadeia através do consenso social (consulte o incidente The DAO de 2016 que levou à bifurcação do Ethereum em ETH e ETC). Se alguém tentar fazer um fork malicioso, todos também devem escolher qual fork “mais confiável” seguir através do consenso social. (Por exemplo, a maioria das pessoas não segue o projeto ETHW)

O consenso social é a causa raiz de garantir a operação ordenada de projetos de blockchain e até mesmo os protocolos DeFi que eles carregam, e até mesmo mecanismos de correção de erros, como auditorias de código de contrato e membros da comunidade divulgando problemas em um projeto também fazem parte do consenso social. No entanto, a descentralização, que é alcançada unicamente pela tecnologia, muitas vezes não desempenha o papel mais importante, e muitas vezes permanece no nível teórico.

O que realmente desempenha um papel em um momento crítico é, muitas vezes, um consenso social que não tem nada a ver com tecnologia, uma supervisão da opinião pública que não tem nada a ver com trabalhos acadêmicos e um reconhecimento em massa que não tem nada a ver com a narrativa técnica. **

Podemos imaginar o seguinte cenário: uma cadeia pública de prisioneiros de guerra de que apenas algumas centenas de pessoas ouviram falar está temporariamente em um estado altamente descentralizado, porque não há domínio de uma empresa. No entanto, se uma empresa de máquinas de mineração de repente investe todo o seu poder de computação na cadeia POW, o poder de computação de si mesmo é muitas vezes maior do que o de todos os outros mineradores, e neste momento, a descentralização da cadeia POW será desintegrada instantaneamente. Se a empresa de máquinas de mineração pretende fazer o mal, as pessoas só podem corrigir o erro através do consenso social. **

Por outro lado, a chamada Camada 2, por mais elaborada que seja a sua conceção de mecanismos, não consegue evitar a ligação de consensos sociais, mesmo L2 como Fuel, DeGate e ZKSpace, que são quase impossíveis para os funcionários fazerem o mal, ** a Layer1-Ethereum em que se baseiam é altamente dependente do consenso social/supervisão da comunidade-opinião pública. **

ALÉM DISSO, ACREDITAMOS QUE O CONTRATO NÃO É ATUALIZÁVEL, PORQUE OUVIMOS AS DECLARAÇÕES DOS AUDITORES DO CONTRATO E DA L2BEAT, MAS ESSAS INSTITUIÇÕES PODEM SER NEGLIGENTES OU MENTIR. Embora essa probabilidade seja extremamente baixa, temos que admitir que ** ainda introduz uma pequena suposição de confiança nela. **

No entanto, a natureza de código aberto do blockchain em si permite que qualquer pessoa, incluindo hackers, verifique se o contrato contém lógica maliciosa, o que realmente minimiza a suposição de confiança, o que reduz muito o custo do consenso social. Se este custo for reduzido o suficiente, podemos assumir que é “sem confiança”.

É claro que, além dos três mencionados acima, o outro Layer2 não tem a chamada confiança, e o que realmente garante segurança em momentos críticos ainda é o consenso social, e o componente técnico muitas vezes é apenas conveniente para as pessoas realizarem a supervisão do consenso social. Se um projeto é tecnicamente superior, mas não amplamente reconhecido e incapaz de atrair uma grande comunidade, então sua governança descentralizada e consenso social em si não será eficaz na execução eficaz.

A tecnologia é importante, mas, na maioria das vezes, a capacidade de ser amplamente reconhecida e a capacidade de desenvolver uma forte cultura comunitária é um fator mais importante, mais valioso e mais propício para o desenvolvimento do projeto do que a tecnologia. **

Podemos muito bem tomar o zkRollup como exemplo, atualmente, muitos zkRollups implementam apenas o sistema de prova de validade e dados DA na cadeia, o que pode provar que todas as transações e transferências de usuários que eles processam são válidas, não forjadas pelo sequenciador, e não há nenhum mal na questão da “transição de estado”, mas não há apenas um cenário em que o oficial ou sequenciador da Layer2 é mau.

Podemos aproximar que o sistema de prova ZK essencialmente só reduz muito o custo da supervisão das pessoas da Camada 2, mas há muitas coisas que não podem ser resolvidas pela própria tecnologia, e devem contar com a intervenção da governança humana ou do consenso social.

Se o funcionário L2 não configurar saídas resistentes à censura, como retiradas forçadas, ou se o funcionário tentar atualizar o contrato e misturá-lo com a lógica de que os ativos do usuário podem ser roubados, os membros da comunidade terão que confiar no consenso social e na fermentação da opinião pública para corrigir seus erros. Neste momento, parece que a superioridade da tecnologia não é mais o mais importante, não tanto se a tecnologia é importante para a segurança, mas sim que o próprio design do mecanismo que é conveniente para as pessoas realizarem o consenso social é mais importante, que é realmente o verdadeiro significado de Layer2 e até mesmo blockchain. **

A partir de Blast, que é supervisionado unicamente pelo consenso social, devemos olhar mais diretamente para a relação entre consenso social e implementação técnica, em vez de julgar os méritos de um projeto baseado em “que L2 está mais perto da Camada 2 na boca de vitalik do que o outro”. Quando um projeto ganha a aprovação e a atenção de milhões de pessoas, um consenso social é formado, e não importa se é uma narrativa de marketing ou técnica, porque o resultado em si é mais importante do que o processo.

É verdade que o consenso social em si é uma extensão da política democrática, e o mundo real confirmou os defeitos da governança democrática, mas o código aberto e a transparência de dados que vem com o blockchain em si reduzem muito o custo do consenso social, então a “regra do homem” da Web3 é essencialmente diferente da “regra do homem” dos países soberanos reais. **

** Se olharmos para o blockchain em si como um meio técnico para melhorar a questão da transparência da informação na governança democrática, em vez de simplesmente perseguir a interminável “implementação sem confiança do código”, tudo parece ser muito mais otimista e claro. Somente livrando-se da arrogância e do preconceito fixados pela elite técnica e abraçando um público mais amplo é que o sistema Ethereum Layer2 pode realmente se tornar uma infraestrutura financeira de classe mundial para adoção em massa.

Ver original
Isenção de responsabilidade: As informações contidas nesta página podem ser provenientes de terceiros e não representam os pontos de vista ou opiniões da Gate. O conteúdo apresentado nesta página é apenas para referência e não constitui qualquer aconselhamento financeiro, de investimento ou jurídico. A Gate não garante a exatidão ou o carácter exaustivo das informações e não poderá ser responsabilizada por quaisquer perdas resultantes da utilização destas informações. Os investimentos em ativos virtuais implicam riscos elevados e estão sujeitos a uma volatilidade de preços significativa. Pode perder todo o seu capital investido. Compreenda plenamente os riscos relevantes e tome decisões prudentes com base na sua própria situação financeira e tolerância ao risco. Para mais informações, consulte a Isenção de responsabilidade.
Comentar
0/400
Nenhum comentário