From Blast to Layer 2 Multisig Backdoor: Por que o consenso social é mais importante do que a tecnologia?

Autor: Fausto, geek web3

Introdução: O subtexto de Blast em face de Layer2 ortodoxa como Polygon zkEVM pode ser “Generais principescos, você preferiria ter um tipo?” Uma vez que todos não estão confiando o suficiente, e a essência é confiar no consenso social para garantir a segurança, por que se preocupar em criticar a concentração de Layer2 do Blast não é alta o suficiente, “Por que é muito ansioso para fritar uns aos outros”?

É 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 um momento em que a Camada 2 mainstream quase todos têm riscos de segurança, como multiassinatura, criticar a Blast por não ser segura o suficiente é mais como o “desprezo” 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. Em menos de 5 dias após seu lançamento, o endereço de recarga Blast atraiu mais de US$ 400 milhões em TVL. Não é exagero dizer que o BLast é como um medicamento forte em um longo mercado de baixa, que instantaneamente desperta 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, que 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 a estrutura do 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.

A grande maioria dos Rollups depende de um conjunto de contratos de gerenciamento de várias assinaturas para atualizar suas permissões, e outros Layer2 acusam “Blast with multi-signature” como 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.

(图源:Academia WTF)

De acordo com os dados do L2BEAT, os principais rollups como Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet e Polygon ZKEVM usam contratos de atualização autorizados com várias assinaturas, que podem ser atualizados imediatamente ignorando o limite de timelock. (Você pode ler o artigo anterior do Geek na web3: The Game of Credit: Rollups Manipulated by Multisig and Commission)

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 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, o engenheiro da Polygon que criticou Blast acima também mencionou isso, mas de uma maneira vaga.

Qual é, então, o significado da existência deste “modo de emergência”? Por que a maioria dos rollups tem que deixar um botão de pânico ou backdoor para si? De acordo com a declaração anterior da 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 certas vulnerabilidades forem exploradas por hackers, isso pode levar ao roubo de um grande número 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 da Camada 2 muitas vezes podem ignorar as restrições de bloqueio de tempo e atualizar imediatamente o código do contrato, o que, de certa forma, parece 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 ao roubo de ativos na 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.

(Para obter mais informações sobre a função de retirada forçada e pod de escape, leia nosso artigo anterior “Qual a importância da função de retirada forçada e escape pod para a camada 2?”)

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

Mas o cerne do problema é que muitos Layer 2s nem sequer configuram uma função de retirada forçada que pode ignorar o sequenciador Sequencer, então o oficial da Camada 2 pode fazer o mal primeiro pedindo ao sequenciador para rejeitar o pedido de retirada de todos e, em seguida, transferir 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 tapete 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 ao limite de atraso de bloqueio de tempo, e 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 efetivo do modo pod de retirada/fuga forçada deve ser reduzido para 48 horas. Desta forma, os usuários podem retirar ativos da Camada 2 para a Camada 1 antes que o contrato seja atualizado depois de descobrir que a equipe do projeto dYdX deseja dopar código malicioso na nova versão do contrato.

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 obrigatório 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.

Embora muitos projetos que adotam o esquema de Validação (DA é implementado off-chain no Ethereum) tenham um longo atraso de atualização de contrato (como 8 dias ou mais), o Validium geralmente depende de nós de DAC off-chain para publicar os dados mais recentes, e o DAC pode lançar um ataque de retenção de dados para invalidar a função de retirada forçada, portanto, não atende 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 podem confiar no projeto de Camada 2 ou no comitê de segurança criado por ele para não fazer o mal, ou confiar nos nós do DAC sob a cadeia para não conluio, ou confiar 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 ser alcançada pelo 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, os fundadores da Avalanche e 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 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 uma cadeia pública tradicional de Camada 1 tem um comportamento maligno que causa danos a um grande número de ativos de usuário, ela muitas vezes abandona a cadeia problemática e bifurca uma nova cadeia por meio de 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 o funcionamento ordenado de projetos de blockchain e até mesmo os protocolos DeFi que eles carregam, mesmo que seja um mecanismo de correção de erros, como auditoria de código de contrato e membros da comunidade divulgando problemas em um projeto, também faz 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 narrativas tecnológicas.

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 pode evitar a ligação de consensos sociais, mesmo L2 como Fuel, DeGate e ZKSpace, que os funcionários dificilmente podem fazer mal, a própria Layer1-Ethereum em que se baseiam é altamente dependente do consenso social/supervisão da opinião pública da comunidade.

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 uma pequena suposição de confiança foi introduzida para ela.

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 das três mencionadas acima, a outra Camada 2 não tem a chamada falta de 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 tem tecnologia superior, mas não é amplamente reconhecido e não pode atrair uma grande comunidade, então sua governança descentralizada e consenso social em si não será eficaz para se desenvolver.

A tecnologia é importante, mas, na maioria das vezes, a capacidade de ser amplamente reconhecido e desenvolver uma forte cultura comunitária é um fator mais importante, valioso e 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 muitas coisas 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 já não é o mais importante, não tanto se a tecnologia é importante para a segurança, mas sim o próprio design do mecanismo que facilita as pessoas a realizarem o consenso social, que é realmente o verdadeiro significado da Camada 2 e até mesmo do blockchain.

A partir do Blast, que é supervisionado exclusivamente pelo consenso social, devemos olhar para a relação entre consenso social e implementação técnica mais diretamente, em vez de julgar os méritos de um projeto baseado em “que L2 está mais próximo da Camada 2 do que o outro L2”. 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 depende de marketing ou narrativas técnicas, 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 do blockchain em si reduzem muito o custo do consenso social, então a “regra do homem” da Web3 é fundamentalmente diferente da “regra do homem” de 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 nunca alcançável “implementação sem confiança de código”, tudo parece ser muito mais otimista e claro. Somente livrando-se da arrogância e do preconceito que a elite técnica fixou 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.