Introdução: O subtexto do Blast enfrentando camada 2 ortodoxa como Polygon zkEVM pode ser, "Os príncipes, generais e ministros prefeririam ter o seu próprio tipo?" Uma vez que nem todos são suficientemente confiáveis e essencialmente dependem do consenso social para garantir a segurança, por que criticar o Blast? A concentração da Camada 2 não é alta o suficiente, então por que a pressa?

É verdade que a dependência da Blast em 3/5 multi-assinaturas para controlar os endereços de recarga tem sido amplamente criticada, mas a maioria dos Layer 2 também depende de multi-assinaturas para gerenciar contratos. Anteriormente, a Optimism até usava apenas um endereço EOA para controlar as permissões de atualização do contrato. Em um momento em que quase todos os Layer 2 mainstream têm riscos de segurança, como multi-assinatura, criticar a Blast por não ser segura o suficiente é mais como "olhar para baixo" para um projeto de mineração de ouro por elites técnicas.

Mas, além da questão de qual é melhor entre os dois acima, a importância da existência do blockchain é mais para resolver o problema da opacidade da informação no consenso social/governação democrática. Ao advogar a supremacia da tecnologia, devemos admitir que o consenso social em si é mais importante do que a tecnologia é importante porque é a base para garantir o funcionamento eficaz de todos os projetos Web3. Em última análise, a tecnologia serve ao consenso social. Um projeto que não pode ser reconhecido pela maioria das pessoas, não importa quão superior seja a tecnologia, é essencialmente apenas um apêndice magnífico.

Recentemente, o novo projeto Blast lançado pelo fundador do Blur tornou-se popular em toda a Internet. Este protocolo de 'ganhos de juros sobre ativos' sob a bandeira da Camada 2 estabeleceu um endereço de recarga na cadeia ETH. Depois que os usuários depositam fundos no endereço Blast, esses fundos serão usados para apostas nativas na rede ETH, colocando-os no MakerDAO para ganhar juros, etc. Os lucros serão devolvidos aos usuários.

Contando com a aura do fundador e a jogabilidade atrativa, Blast recebeu US$20 milhões em financiamento de investidores liderados pela Paradigm e também atraiu a participação de inúmeros investidores varejistas. Em menos de 5 dias desde o seu lançamento, o endereço de recarga da Blast atraiu mais de 400 milhões de dólares em TVL. Não é exagero dizer que a Blast é como uma forte dose de medicamento no longo mercado baixista, despertando instantaneamente o entusiasmo das pessoas.

No entanto, embora o Blast tenha alcançado sucesso inicial, também atraiu dúvidas de muitos especialistas. Por exemplo, L2BEAT e engenheiros da Polygon foram diretos: o atual Blast apenas implanta o contrato de Depósito para receber recargas no Ethereum. Este contrato pode ser atualizado sob o controle de 3/5 multi-assinaturas. Em outras palavras, a lógica de código do contrato pode ser reescrita, se você quiser rugir, ainda pode rugir. Ao mesmo tempo, o Blast apenas afirma implementar a estrutura Rollup, mas agora é apenas uma casca vazia, e nem mesmo a função de retirada será lançada até fevereiro do próximo ano.

Camada 2 de assinatura múltipla é um problema de longa data

Na verdade, a multiassinatura de contratos da Camada 2 é um problema antigo. Já em julho deste ano, a L2BEAT realizou uma pesquisa especial sobre a capacidade de atualização do contrato Rollup. A chamada 'capacidade de atualização' significa alterar o endereço lógico do contrato apontado pelo contrato agente para alcançar o efeito de mudar a lógica do contrato. Se o novo contrato alterado contiver lógica maliciosa, os oficiais da Camada 2 podem roubar os ativos do usuário.

(Fonte: academia wtf)

De acordo com os dados do L2BEAT, os rollups principais atuais, como Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM, etc., todos usam contratos atualizáveis de autorização de multi-assinatura, que podem contornar restrições de bloqueio de tempo e ser atualizados imediatamente. (Você pode ler artigos anteriores do Geek Web3:O Jogo do Crédito: Rollups Controlados por Multi-Assinaturas e Comitês )

O que é surpreendente é que a Optimism costumava usar apenas um endereço EOA para gerenciar atualizações de contrato, e mesmo as assinaturas múltiplas só foram adicionadas em outubro deste ano. Quanto ao zkEVM da Polygon, que criticou o Blast, também pode realizar uma "tomada de controle de emergência" do contrato Rollup sob a autorização de multi-assinatura 6/8, transformando a Camada 2 de governança de contrato em governança humana "nua". Curiosamente, o engenheiro da Polygon que criticou o Blast acima também mencionou isso, mas foi vago.

Qual é a importância deste 'modo de emergência'? Por que a maioria dos Rollups deixa um botão de pânico ou uma porta dos fundos? Segundo declaração anterior de Vitalik, Rollup precisa atualizar frequentemente os contratos implantados na ETH durante o processo de iteração. Sem a introdução de meios atualizáveis como contratos de agência, será difícil iterar de forma eficiente.

Além disso, contratos inteligentes que hospedam uma grande quantidade de ativos podem ter bugs sutis, e a equipe de desenvolvimento da Camada 2 é inevitavelmente negligente. Se certas vulnerabilidades forem exploradas por hackers, uma grande quantidade de ativos pode ser roubada. Portanto, seja na Camada 2 ou nos protocolos DeFi, um botão de emergência é frequentemente configurado, e os “membros do comitê” intervêm quando necessário para evitar que certos eventos malignos ocorram.

Claro, o comitê criado pela Camada 2 muitas vezes pode contornar restrições de bloqueio de tempo e atualizar imediatamente o código do contrato. De certa forma, eles parecem ser mais tabu do que fatores externos como hackers. Em outras palavras, em qualquer caso, contratos inteligentes que hospedam grandes quantidades de ativos são difíceis de evitar um certo grau de 'pressuposição de confiança', ou seja, presume-se que o controlador de múltiplas assinaturas por trás do contrato não faça o mal. A menos que o contrato seja projetado para ser não-atualizável e não haja bugs que possam ameaçar a segurança dos ativos do usuário.

A situação real é que a Camada 2 principal atual permite que seu próprio comitê atualize imediatamente o contrato, ou introduz restrições de bloqueio de tempo relativamente curtas (por exemplo, qualquer um que queira atualizar o contrato dYdX terá um atraso de pelo menos 48 horas). Se for descoberto que o comitê pretende incorporar lógica maliciosa na nova versão do código do contrato para roubar ativos, os usuários teoricamente terão tempo de reação suficiente para retirar urgentemente seus ativos da Camada 1.

(Para obter informações sobre a retirada forçada e as funções da cabine de escape, você pode ler nosso artigo anterior “Quão importantes são a retirada forçada e as funções de cabine de escape para a Camada 2?“

(O bloqueio de tempo permite que você execute certas operações após um atraso)

Mas a essência do problema é que muitas Camada 2 nem sequer têm uma função de saque forçado que possa contornar o Sequenciador. Se os oficiais da Camada 2 quiserem fazer algo de ruim, eles podem primeiro fazer com que o Sequenciador rejeite os pedidos de saque de todos e, em seguida, dividir os ativos do usuário. Vá para a conta L2 controlada pelos próprios oficiais da Camada 2. Depois, o oficial irá atualizar o contrato Rollup de acordo com suas próprias necessidades. Após o término do atraso de bloqueio de tempo, todos os ativos do usuário podem ser transferidos para a cadeia ETH.

Claro, a situação real pode ser pior do que eu disse, pois a maioria dos funcionários do Rollup pode atualizar contratos sem restrições de bloqueio de tempo, o que significa que tapetes no valor de centenas de milhões de dólares podem ser concluídos quase instantaneamente.

Uma Camada 2 verdadeiramente sem confiança deve fazer com que a atualização do contrato tenha um atraso maior do que o atraso de saque forçado.

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

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

Qualquer pessoa que queira atualizar o contrato da Camada 2 deve estar sujeita ao limite de atraso do bloqueio de tempo, e a atualização do contrato deve entrar em vigor posteriormente à retirada obrigatória. Por exemplo, a atualização do contrato da dYdX agora tem um atraso de pelo menos 48 horas, portanto, o atraso para a retirada forçada/modo de saída de emergência entrar em vigor deve ser reduzido para dentro de 48 horas. Dessa forma, depois que os usuários descobrirem que a equipe do projeto dYdX quer incorporar código malicioso na nova versão do contrato, eles poderão retirar seus ativos da Camada 2 para a Camada 1 antes que o contrato seja atualizado.

Atualmente, a grande maioria dos rollups que lançaram um mecanismo de cabine de retirada/escape forçada não atendem às condições acima. Por exemplo, a saída de emergência/escapada forçada da dYdX tem um atraso máximo de 7 dias, mas o atraso de atualização do contrato do comitê dYdX é de apenas 48 horas. Em outras palavras, o comitê pode concluir a implantação do novo contrato antes que a retirada forçada do usuário entre em vigor. Roubar ativos antes que o usuário escape.

Sob essa perspectiva, exceto Fuel, ZKSpace e Degate, outros Rollups não podem garantir que as retiradas forçadas dos usuários serão processadas antes da atualização do contrato, e há um alto grau de assumção de confiança.

Embora muitos projetos que usam a solução Validium (DA é implementado fora da cadeia Ethereum) tenham atrasos longos na atualização do contrato (como 8 dias ou mais), o Validium muitas vezes depende dos nós DAC fora da cadeia para publicar os dados mais recentes, e o DAC pode lançar ataques de retenção de dados desativando a função de saque forçado e, portanto, não está em conformidade com o modelo de segurança discutido acima. (Você pode ler nosso artigo anterior “Disparando Validium? Re-entendendo a Camada 2 a partir da perspectiva do proponente Danksharding“ )

Neste ponto, parece que podemos chegar a uma conclusão concisa e clara: As soluções de Camada 2 além de Fuel, ZKSpace e DeGate não são confiáveis. Os usuários precisam confiar ou na parte do projeto de Camada 2 ou no comitê de segurança estabelecido por ele para não fazer o mal, confiar nos nós DAC fora da cadeia para não colaborar, ou confiar no sequenciador para não revisar sua transação (rejeitar sua solicitação). Atualmente, existem apenas as três Camadas 2 mencionadas acima que atendem verdadeiramente aos requisitos de segurança, resistência à censura e confiabilidade.

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

Na verdade, o tópico sobre o qual estamos falando hoje não é novo. A essência da Camada 2 apontada neste artigo depende da credibilidade da parte do projeto, como apontado por inúmeras pessoas. Por exemplo, os fundadores da Avalanche e Solana criticaram ferozmente isso, mas o problema é que essas suposições de confiança que existem na Camada 2 também existem na Camada 1 e até em todos os projetos de blockchain.

Por exemplo, precisamos assumir que os nós validadores que representam 2/3 do peso da garantia na rede Solana não colidem, e precisamos assumir que os dois principais grupos de mineração que representam a maioria do poder de computação do Bitcoin não se unem 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 “impossível.”

Uma vez que uma cadeia pública tradicional da Camada 1 cometa um ato maligno que cause uma grande quantidade de ativos de usuários a serem danificados, frequentemente abandonará a cadeia problemática e bifurcará uma nova cadeia por meio de consenso social (consulte o incidente DAO em 2016 que levou ao Fork do Ethereum em ETH e ETC). Se alguém tentar um fork malicioso, todos devem escolher qual fork “mais confiável” seguir por meio de consenso social. (Por exemplo, a maioria das pessoas não segue o projeto ETHW)

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

O que realmente entra em jogo nos momentos críticos muitas vezes é o consenso social que não tem nada a ver com tecnologia, a supervisão da opinião pública que não tem nada a ver com artigos acadêmicos e o reconhecimento em massa que não tem nada a ver com narrativas técnicas.

Podemos imaginar o seguinte cenário: uma cadeia pública POW da qual apenas algumas centenas de pessoas ouviram falar está temporariamente em um estado altamente descentralizado porque ainda não houve uma situação em que uma empresa seja dominante. Mas se uma empresa de mineração investir repentinamente todo o seu poder de computação na cadeia POW, seu poder de computação será muitas vezes maior do que o de todos os outros mineradores. Neste momento, a descentralização desta cadeia POW será instantaneamente colapsada. Se a empresa de mineração tiver a intenção de fazer o mal, as pessoas só poderão corrigir o erro por meio do consenso social.

Por outro lado, o chamado Camada 2, por mais sofisticado que seja seu design de mecanismo, não pode evitar o elo do consenso social. Mesmo L2s como Fuel, DeGate e ZKSpace, que são quase impossíveis para os oficiais fazerem o mal, o Camada 1-Ethereum em que eles dependem também depende muito de consenso social/supervisão da comunidade-opinião pública.

Além disso, acreditamos que o contrato não pode ser atualizado porque ouvimos as submissões da agência de auditoria de contratos e da L2BEAT, mas essas agências podem ser negligentes ou mentir. Embora essa probabilidade seja extremamente baixa, temos que admitir que uma pequena suposição de confiança ainda é introduzida.

No entanto, a natureza de dados de código aberto da própria blockchain permite que qualquer pessoa, incluindo hackers, verifique se o contrato contém lógica maliciosa. De fato, a suposição de confiança foi minimizada, o que reduz consideravelmente o custo do consenso social. Se esse custo for reduzido a um nível baixo o suficiente, podemos assumir a "falta de confiança".

Claro, exceto pelas três empresas mencionadas acima, outras Camada 2 não têm qualquer chamado de confiança. O que realmente garante a segurança nos momentos críticos ainda é o consenso social. O componente técnico muitas vezes é apenas para facilitar as pessoas a realizarem a supervisão do consenso social. Se a tecnologia de um projeto é superior, mas não é amplamente reconhecida e não consegue atrair um grande grupo de comunidade, então sua governança descentralizada e o próprio consenso social serão difíceis de desenvolver efetivamente.

A tecnologia é, de fato, importante, mas, na maioria das vezes, se ela pode ser amplamente reconhecida e se pode desenvolver uma forte cultura comunitária são fatores mais importantes, mais valiosos e mais propícios para o desenvolvimento do projeto do que a tecnologia.

Poderíamos muito bem tomar o zkRollup como exemplo. Atualmente, muitos zkRollups implementam apenas o sistema de certificação de validade e dados DA on-chain. Ele pode provar externamente que as transações do usuário que ele manipula e todas as transferências realizadas são válidas e não falsificadas pelo sequenciador. Em "Não há maldade neste assunto de "transição de estado", mas este não é o único cenário onde os funcionários ou sequenciadores da Camada 2 fazem maldade.

Podemos aproximar que o sistema de prova ZK essencialmente apenas reduz consideravelmente o custo da supervisão das pessoas da Camada 2, mas há muitas coisas que não podem ser resolvidas pela tecnologia em si e devem depender da intervenção da governança humana ou do consenso social.

Se os funcionários da L2 não configurarem saídas anticensura, como retiradas forçadas, ou se os funcionários tentarem atualizar o contrato e incorporar lógicas que podem roubar os ativos dos usuários, os membros da comunidade terão que confiar no consenso social e na fermentação da opinião pública para corrigir erros. Neste momento, se a tecnologia é superior ou não parece mais ser o mais importante. Em vez de dizer que a tecnologia é importante para a segurança, é mais importante dizer que o próprio design do mecanismo facilita

Do Blast, que depende puramente do consenso social para supervisão, devemos olhar para a relação entre o consenso social e a implementação técnica de forma mais direta, em vez de simplesmente julgar “qual L2 está mais perto da Camada 2 mencionada por Vitalik do que o outro L2” Determinar os méritos de um projeto. Quando um projeto ganha reconhecimento e atenção de milhões de pessoas, um consenso social é formado. Não importa se ele depende de marketing ou narrativa 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 as deficiências da governança democrática. No entanto, a transparência de código aberto e de dados do blockchain reduziu muito o custo do consenso social. Portanto, há uma diferença essencial entre a "governança pelo homem" e a "governança pelo homem" nos estados soberanos reais.

Se considerarmos o próprio blockchain como um meio técnico para melhorar questões de transparência da informação na governança democrática, em vez de simplesmente buscar 'Confiança alcançada puramente por código' que nunca está ao alcance, tudo parece se tornar muito mais otimista e claro. Somente ao se livrar da arrogância e preconceito inerentes à elite técnica e abraçar uma audiência mais ampla, o sistema Ethereum Camada 2 pode realmente se tornar uma infraestrutura financeira de classe mundial com adoção em massa.

Aviso legal:

1. Este artigo é reproduzido de [Conta oficial do WeChat: Geek Web3]. Todos os direitos autorais pertencem ao autor original [Faust]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.