Introdução: O subtexto do Blast enfrentando a camada 2 ortodoxa, como o Polygon zkEVM, pode ser: "Os príncipes, generais e ministros prefeririam ter seu próprio tipo?" Uma vez que nem todos são suficientemente confiáveis e dependem essencialmente 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 do Blast em 3/5 multi-assinaturas para controlar os endereços de recarga tem sido amplamente criticada, mas a maioria da Camada 2 também depende de multi-assinaturas para gerir contratos. Anteriormente, a Optimism até usava apenas um endereço EOA para controlar as permissões de atualização do contrato. Num momento em que quase todas as Camadas 2 principais têm riscos de segurança, como multi-assinaturas, criticar o Blast por não ser suficientemente seguro é mais como 'olhar de cima' 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 da blockchain é mais 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 a operação eficaz de todos os projetos Web3. Em última análise, a tecnologia serve o consenso social. Um projeto que não pode ser reconhecido pela maioria das pessoas, não importa o quão superior seja a tecnologia, é essencialmente apenas um apêndice deslumbrante.
Texto: Recentemente, o novo projeto Blast lançado pelo fundador da Blur tornou-se popular em toda a Internet. Este protocolo de "ganho de juros de 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 do Blast, esses fundos serão usados para aposta nativa na rede ETH, colocando-os na MakerDAO para ganhar juros, etc. Os lucros serão devolvidos aos usuários.
Com base na aura do fundador e no jogo atrativo, Blast recebeu 20 milhões de dólares 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 desde o seu lançamento, o endereço de recarga do Blast atraiu mais de 400 milhões de dólares em TVL. Não é exagero dizer que o Blast é como uma forte dose de medicamento no longo mercado de urso, 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, os engenheiros da L2BEAT e da Polygon foram diretos: O atual Blast apenas implementa 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 fazer uma fraude, ainda pode fazê-lo. Ao mesmo tempo, o Blast apenas afirma implementar a estrutura Rollup, mas agora é apenas uma casca vazia, e nem mesmo a função de saque será lançada até fevereiro do próximo ano.
Na verdade, a multi-assinatura de contratos da Camada 2 é um problema antigo. Já em julho deste ano, a L2BEAT conduziu 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 de agente para alcançar o efeito de alterar a lógica do contrato. Se o novo contrato alterado contiver lógica maliciosa, os oficiais da Camada 2 podem roubar os ativos dos usuários.
(Fonte: academia wtf)
De acordo com os dados da L2BEAT, os rollups principais atuais, como Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM, etc., todos utilizam contratos de atualização autorizados de múltiplas assinaturas, que podem contornar restrições de bloqueio de tempo e ser atualizados imediatamente. (Pode ler os artigos anteriores da 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 gerir atualizações de contrato, e até mesmo as multi-assinaturas só foram adicionadas em outubro deste ano. Quanto ao Polygon zkEVM, que criticou o Blast, também pode realizar uma “tomada de controle de emergência” do contrato Rollup sob autorização de multi-assinatura 6/8, transformando a Camada 2 de governança de contrato em uma 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 porta dos fundos? De acordo com a declaração anterior de Vitalik, o Rollup precisa de atualizações frequentes nos contratos implantados no ETH durante o processo de iteração. Sem a introdução de meios atualizáveis como contratos de agência, será difícil iterar eficientemente.
Além disso, os 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, quer seja a Camada 2 ou os protocolos DeFi, frequentemente é criado um botão de emergência, e os "membros do comitê" intervêm quando necessário para prevenir a ocorrência de certos eventos malignos.
Claro, o comitê criado pela Camada 2 pode muitas vezes contornar as restrições de bloqueio de tempo e atualizar imediatamente o código do contrato. De certa perspectiva, eles parecem ser mais tabu do que fatores externos como hackers. Em outras palavras, em qualquer caso, os contratos inteligentes que hospedam grandes quantidades de ativos são difíceis de evitar um certo grau de “pressuposto 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 atual é 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 pessoa 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 no novo código de contrato para roubar ativos, os utilizadores teoricamente terão tempo suficiente para reagir urgentemente e retirar os seus ativos da Camada 1.
(Para obter informações sobre as funções de retirada forçada e escape da cabine, você pode ler nosso artigo anterior " Quão importantes são as funções de retirada forçada e de cabine de escape para a Camada 2?“
(O bloqueio de tempo permite que realize certas operações após um atraso)
Mas a questão central 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 mal, podem primeiro deixar o Sequenciador rejeitar os pedidos de saque de todos e depois dividir os ativos do usuário. Ir para a conta L2 controlada pelos próprios oficiais da Camada 2. Depois disso, o oficial irá atualizar o contrato Rollup de acordo com suas próprias necessidades. Após o término do atraso do 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 o que eu disse, porque a maioria dos oficiais da Camada 2 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 o atraso na atualização do contrato seja maior do que o atraso na retirada forçada.
Na verdade, para resolver o problema de falta de confiança/segurança da Camada 2, as seguintes coisas precisam ser feitas:
Configurar uma saída de saque resistente à censura na Camada 1 e os utilizadores podem sacar ativos diretamente da Camada 2 para a cadeia ETH sem permissão do sequenciador. O atraso para saque forçado não deve ser muito longo, para garantir que os ativos do utilizador possam ser sacados da L2 rapidamente;
Qualquer pessoa que queira atualizar o contrato da Camada 2 deve estar sujeita ao limite de atraso de bloqueio temporal, 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 que a retirada forçada/modo de saída de emergência entre em vigor deve ser reduzido para menos de 48 horas. Dessa forma, depois que os usuários descobrirem que a equipe do projeto dYdX deseja incorporar código malicioso na nova versão do contrato, eles podem 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/fuga forçada não cumprem as condições acima. Por exemplo, a escotilha de retirada/fuga forçada da dYdX tem um atraso máximo de 7 dias, mas o atraso na atualização do contrato do comitê da dYdX é de apenas 48 horas. Em outras palavras, o comitê pode concluir a implementação do novo contrato antes que a retirada forçada do usuário entre em vigor. Roube ativos antes que o usuário escape.
Desta perspetiva, exceto Fuel, ZKSpace e Degate, outros Rollups não podem garantir que as retiradas forçadas dos utilizadores serão processadas antes da atualização do contrato e há um alto grau de pressuposição de confiança.
Embora muitos projetos que usam a solução Validium (DA é implementado fora da cadeia Ethereum) tenham longos atrasos na atualização do contrato (como 8 dias ou mais), o Validium muitas vezes depende dos nós DAC off-chain para publicar os dados mais recentes, e o DAC pode lançar ataques de retenção de dados desativar a função de saque forçado e, portanto, não estão em conformidade com o modelo de segurança discutido acima. (Você pode ler nosso artigo anterior “Disparar Validium? Reentender a Camada 2 a partir da perspetiva do proponente Danksharding“ )
Neste ponto, parece que podemos tirar uma conclusão concisa e clara: as soluções de Camada 2 que não sejam Fuel, ZKSpace e DeGate não são confiáveis. Os utilizadores têm de confiar na parte do projeto da Camada 2 ou no comité de segurança por ela criado para não agir de forma maliciosa, confiar nos nós DAC fora da cadeia para não conspirar, ou confiar no sequenciador para não rever a sua transação (rejeitar o seu pedido). Atualmente, apenas as três Camadas 2 acima mencionadas cumprem verdadeiramente os requisitos de segurança, resistência à censura e falta de confiança.
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 a falar hoje não é novo. A essência da Camada 2 apontada neste artigo depende da credibilidade da parte do projeto, que foi apontada por inúmeras pessoas. Por exemplo, os fundadores da Avalanche e da 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 promessa 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 de Camada 1 comete um ato maléfico que causa danos a um grande número de ativos de usuários, muitas vezes ela abandonará a cadeia problemática e bifurcará uma nova cadeia através de consenso social (consulte o incidente DAO em 2016 que levou ao Ethereum bifurcar-se em ETH e ETC). Se alguém tentar uma bifurcação maliciosa, todos devem escolher qual bifurcação “mais confiável” seguir através de consenso social. (Por exemplo, a maioria das pessoas não segue o projeto party ETHW)
O consenso social é a raiz de garantir a operação ordenada de projetos de blockchain e até mesmo dos protocolos DeFi que eles carregam. Até mesmo mecanismos de correção de erros, como auditorias de código de contrato e membros da comunidade que divulgam problemas com um projeto, fazem parte do consenso social. No entanto, a descentralização alcançada unicamente pela tecnologia muitas vezes falha em desempenhar o seu maior papel e frequentemente permanece no nível teórico.
O que realmente entra em jogo nos momentos críticos é frequentemente 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 trabalhos 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 de POW que apenas algumas centenas de pessoas ouviram falar está temporariamente num 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 de POW, o seu poder de computação será muitas vezes superior ao de todos os outros mineiros. Neste momento, a descentralização desta cadeia de POW irá colapsar instantaneamente. Se a empresa de mineração tiver intenções malignas, as pessoas só poderão corrigir o erro através do consenso social.
Por outro lado, a chamada Camada 2, por mais sofisticado que seja o seu design de mecanismo, não consegue 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 Layer 1-Ethereum em que eles confiam também depende fortemente do 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 L2BEAT, mas essas agências podem ser negligentes ou mentir. Embora essa probabilidade seja extremamente baixa, temos de admitir que é introduzida uma pequena suposição de confiança.
No entanto, a natureza de dados de código aberto da própria blockchain permite a qualquer pessoa, incluindo hackers, verificar se o contrato contém lógica maliciosa. Na verdade, a suposição de confiança foi minimizada, o que reduz muito o custo do consenso social. Se este custo for reduzido a um nível suficientemente baixo, podemos recorrer à “ausência de confiança”.
Claro, excepto pelas três empresas mencionadas acima, outras Camada 2 não têm qualquer tipo 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 serve para facilitar as pessoas a realizar a supervisão do consenso social. Se a tecnologia de um projeto for superior, mas não for amplamente reconhecida e não conseguir atrair um grande grupo de comunidade, então a sua governança descentralizada e o próprio consenso social serão difíceis de desenvolver eficazmente.
A tecnologia é realmente importante, mas na maioria das vezes, se ela pode ser amplamente reconhecida e se pode desenvolver uma forte cultura comunitária são fatores que são mais importantes, mais valiosos e mais propícios ao desenvolvimento de projetos do que a tecnologia.
Podemos muito bem tomar zkRollup como exemplo. Atualmente, muitos zkRollups apenas implementam o sistema de certificação de validade e os dados DA on-chain. Pode provar externamente que as transações do usuário que manipula e todas as transferências realizadas são válidas e não são forjadas pelo sequenciador. Em "Não há mal neste assunto de 'transição de estado', mas este não é o único cenário onde os oficiais ou sequenciadores da Camada 2 fazem o mal.
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 depender da intervenção da governança humana ou do consenso social.
Se os funcionários da Camada 2 não criarem saídas anti-censura, como retiradas forçadas, ou se os funcionários tentarem atualizar o contrato e incorporar lógica que possa roubar ativos dos usuários, os membros da comunidade terão de 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 já não 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 que 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 próximo 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, o consenso social foi formado. Não importa se depende de marketing ou narrativa técnica, porque o resultado em si é mais importante do que o processo.
É verdade que o próprio consenso social é uma extensão da política democrática, e o mundo real confirmou as deficiências da governação democrática. No entanto, o código aberto e a transparência de dados do próprio blockchain reduziram muito o custo do consenso social. Portanto, Web3's Há uma diferença essencial entre "governo pelo homem" e "governo pelo homem" em estados soberanos reais.
Se considerarmos a blockchain em si como um meio técnico para melhorar questões de transparência da informação na governação democrática, em vez de simplesmente perseguir a “Confiança conseguida puramente pelo código” que nunca está ao alcance, tudo parece tornar-se muito mais otimista e claro. Apenas ao livrarmo-nos da arrogância e preconceito inerentes à elite técnica e abraçar uma audiência mais ampla é que o sistema Ethereum Camada 2 pode verdadeiramente tornar-se numa infraestrutura financeira de classe mundial com adoção em massa.
Partilhar
Introdução: O subtexto do Blast enfrentando a camada 2 ortodoxa, como o Polygon zkEVM, pode ser: "Os príncipes, generais e ministros prefeririam ter seu próprio tipo?" Uma vez que nem todos são suficientemente confiáveis e dependem essencialmente 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 do Blast em 3/5 multi-assinaturas para controlar os endereços de recarga tem sido amplamente criticada, mas a maioria da Camada 2 também depende de multi-assinaturas para gerir contratos. Anteriormente, a Optimism até usava apenas um endereço EOA para controlar as permissões de atualização do contrato. Num momento em que quase todas as Camadas 2 principais têm riscos de segurança, como multi-assinaturas, criticar o Blast por não ser suficientemente seguro é mais como 'olhar de cima' 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 da blockchain é mais 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 a operação eficaz de todos os projetos Web3. Em última análise, a tecnologia serve o consenso social. Um projeto que não pode ser reconhecido pela maioria das pessoas, não importa o quão superior seja a tecnologia, é essencialmente apenas um apêndice deslumbrante.
Texto: Recentemente, o novo projeto Blast lançado pelo fundador da Blur tornou-se popular em toda a Internet. Este protocolo de "ganho de juros de 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 do Blast, esses fundos serão usados para aposta nativa na rede ETH, colocando-os na MakerDAO para ganhar juros, etc. Os lucros serão devolvidos aos usuários.
Com base na aura do fundador e no jogo atrativo, Blast recebeu 20 milhões de dólares 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 desde o seu lançamento, o endereço de recarga do Blast atraiu mais de 400 milhões de dólares em TVL. Não é exagero dizer que o Blast é como uma forte dose de medicamento no longo mercado de urso, 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, os engenheiros da L2BEAT e da Polygon foram diretos: O atual Blast apenas implementa 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 fazer uma fraude, ainda pode fazê-lo. Ao mesmo tempo, o Blast apenas afirma implementar a estrutura Rollup, mas agora é apenas uma casca vazia, e nem mesmo a função de saque será lançada até fevereiro do próximo ano.
Na verdade, a multi-assinatura de contratos da Camada 2 é um problema antigo. Já em julho deste ano, a L2BEAT conduziu 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 de agente para alcançar o efeito de alterar a lógica do contrato. Se o novo contrato alterado contiver lógica maliciosa, os oficiais da Camada 2 podem roubar os ativos dos usuários.
(Fonte: academia wtf)
De acordo com os dados da L2BEAT, os rollups principais atuais, como Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM, etc., todos utilizam contratos de atualização autorizados de múltiplas assinaturas, que podem contornar restrições de bloqueio de tempo e ser atualizados imediatamente. (Pode ler os artigos anteriores da 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 gerir atualizações de contrato, e até mesmo as multi-assinaturas só foram adicionadas em outubro deste ano. Quanto ao Polygon zkEVM, que criticou o Blast, também pode realizar uma “tomada de controle de emergência” do contrato Rollup sob autorização de multi-assinatura 6/8, transformando a Camada 2 de governança de contrato em uma 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 porta dos fundos? De acordo com a declaração anterior de Vitalik, o Rollup precisa de atualizações frequentes nos contratos implantados no ETH durante o processo de iteração. Sem a introdução de meios atualizáveis como contratos de agência, será difícil iterar eficientemente.
Além disso, os 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, quer seja a Camada 2 ou os protocolos DeFi, frequentemente é criado um botão de emergência, e os "membros do comitê" intervêm quando necessário para prevenir a ocorrência de certos eventos malignos.
Claro, o comitê criado pela Camada 2 pode muitas vezes contornar as restrições de bloqueio de tempo e atualizar imediatamente o código do contrato. De certa perspectiva, eles parecem ser mais tabu do que fatores externos como hackers. Em outras palavras, em qualquer caso, os contratos inteligentes que hospedam grandes quantidades de ativos são difíceis de evitar um certo grau de “pressuposto 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 atual é 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 pessoa 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 no novo código de contrato para roubar ativos, os utilizadores teoricamente terão tempo suficiente para reagir urgentemente e retirar os seus ativos da Camada 1.
(Para obter informações sobre as funções de retirada forçada e escape da cabine, você pode ler nosso artigo anterior " Quão importantes são as funções de retirada forçada e de cabine de escape para a Camada 2?“
(O bloqueio de tempo permite que realize certas operações após um atraso)
Mas a questão central 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 mal, podem primeiro deixar o Sequenciador rejeitar os pedidos de saque de todos e depois dividir os ativos do usuário. Ir para a conta L2 controlada pelos próprios oficiais da Camada 2. Depois disso, o oficial irá atualizar o contrato Rollup de acordo com suas próprias necessidades. Após o término do atraso do 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 o que eu disse, porque a maioria dos oficiais da Camada 2 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 o atraso na atualização do contrato seja maior do que o atraso na retirada forçada.
Na verdade, para resolver o problema de falta de confiança/segurança da Camada 2, as seguintes coisas precisam ser feitas:
Configurar uma saída de saque resistente à censura na Camada 1 e os utilizadores podem sacar ativos diretamente da Camada 2 para a cadeia ETH sem permissão do sequenciador. O atraso para saque forçado não deve ser muito longo, para garantir que os ativos do utilizador possam ser sacados da L2 rapidamente;
Qualquer pessoa que queira atualizar o contrato da Camada 2 deve estar sujeita ao limite de atraso de bloqueio temporal, 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 que a retirada forçada/modo de saída de emergência entre em vigor deve ser reduzido para menos de 48 horas. Dessa forma, depois que os usuários descobrirem que a equipe do projeto dYdX deseja incorporar código malicioso na nova versão do contrato, eles podem 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/fuga forçada não cumprem as condições acima. Por exemplo, a escotilha de retirada/fuga forçada da dYdX tem um atraso máximo de 7 dias, mas o atraso na atualização do contrato do comitê da dYdX é de apenas 48 horas. Em outras palavras, o comitê pode concluir a implementação do novo contrato antes que a retirada forçada do usuário entre em vigor. Roube ativos antes que o usuário escape.
Desta perspetiva, exceto Fuel, ZKSpace e Degate, outros Rollups não podem garantir que as retiradas forçadas dos utilizadores serão processadas antes da atualização do contrato e há um alto grau de pressuposição de confiança.
Embora muitos projetos que usam a solução Validium (DA é implementado fora da cadeia Ethereum) tenham longos atrasos na atualização do contrato (como 8 dias ou mais), o Validium muitas vezes depende dos nós DAC off-chain para publicar os dados mais recentes, e o DAC pode lançar ataques de retenção de dados desativar a função de saque forçado e, portanto, não estão em conformidade com o modelo de segurança discutido acima. (Você pode ler nosso artigo anterior “Disparar Validium? Reentender a Camada 2 a partir da perspetiva do proponente Danksharding“ )
Neste ponto, parece que podemos tirar uma conclusão concisa e clara: as soluções de Camada 2 que não sejam Fuel, ZKSpace e DeGate não são confiáveis. Os utilizadores têm de confiar na parte do projeto da Camada 2 ou no comité de segurança por ela criado para não agir de forma maliciosa, confiar nos nós DAC fora da cadeia para não conspirar, ou confiar no sequenciador para não rever a sua transação (rejeitar o seu pedido). Atualmente, apenas as três Camadas 2 acima mencionadas cumprem verdadeiramente os requisitos de segurança, resistência à censura e falta de confiança.
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 a falar hoje não é novo. A essência da Camada 2 apontada neste artigo depende da credibilidade da parte do projeto, que foi apontada por inúmeras pessoas. Por exemplo, os fundadores da Avalanche e da 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 promessa 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 de Camada 1 comete um ato maléfico que causa danos a um grande número de ativos de usuários, muitas vezes ela abandonará a cadeia problemática e bifurcará uma nova cadeia através de consenso social (consulte o incidente DAO em 2016 que levou ao Ethereum bifurcar-se em ETH e ETC). Se alguém tentar uma bifurcação maliciosa, todos devem escolher qual bifurcação “mais confiável” seguir através de consenso social. (Por exemplo, a maioria das pessoas não segue o projeto party ETHW)
O consenso social é a raiz de garantir a operação ordenada de projetos de blockchain e até mesmo dos protocolos DeFi que eles carregam. Até mesmo mecanismos de correção de erros, como auditorias de código de contrato e membros da comunidade que divulgam problemas com um projeto, fazem parte do consenso social. No entanto, a descentralização alcançada unicamente pela tecnologia muitas vezes falha em desempenhar o seu maior papel e frequentemente permanece no nível teórico.
O que realmente entra em jogo nos momentos críticos é frequentemente 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 trabalhos 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 de POW que apenas algumas centenas de pessoas ouviram falar está temporariamente num 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 de POW, o seu poder de computação será muitas vezes superior ao de todos os outros mineiros. Neste momento, a descentralização desta cadeia de POW irá colapsar instantaneamente. Se a empresa de mineração tiver intenções malignas, as pessoas só poderão corrigir o erro através do consenso social.
Por outro lado, a chamada Camada 2, por mais sofisticado que seja o seu design de mecanismo, não consegue 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 Layer 1-Ethereum em que eles confiam também depende fortemente do 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 L2BEAT, mas essas agências podem ser negligentes ou mentir. Embora essa probabilidade seja extremamente baixa, temos de admitir que é introduzida uma pequena suposição de confiança.
No entanto, a natureza de dados de código aberto da própria blockchain permite a qualquer pessoa, incluindo hackers, verificar se o contrato contém lógica maliciosa. Na verdade, a suposição de confiança foi minimizada, o que reduz muito o custo do consenso social. Se este custo for reduzido a um nível suficientemente baixo, podemos recorrer à “ausência de confiança”.
Claro, excepto pelas três empresas mencionadas acima, outras Camada 2 não têm qualquer tipo 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 serve para facilitar as pessoas a realizar a supervisão do consenso social. Se a tecnologia de um projeto for superior, mas não for amplamente reconhecida e não conseguir atrair um grande grupo de comunidade, então a sua governança descentralizada e o próprio consenso social serão difíceis de desenvolver eficazmente.
A tecnologia é realmente importante, mas na maioria das vezes, se ela pode ser amplamente reconhecida e se pode desenvolver uma forte cultura comunitária são fatores que são mais importantes, mais valiosos e mais propícios ao desenvolvimento de projetos do que a tecnologia.
Podemos muito bem tomar zkRollup como exemplo. Atualmente, muitos zkRollups apenas implementam o sistema de certificação de validade e os dados DA on-chain. Pode provar externamente que as transações do usuário que manipula e todas as transferências realizadas são válidas e não são forjadas pelo sequenciador. Em "Não há mal neste assunto de 'transição de estado', mas este não é o único cenário onde os oficiais ou sequenciadores da Camada 2 fazem o mal.
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 depender da intervenção da governança humana ou do consenso social.
Se os funcionários da Camada 2 não criarem saídas anti-censura, como retiradas forçadas, ou se os funcionários tentarem atualizar o contrato e incorporar lógica que possa roubar ativos dos usuários, os membros da comunidade terão de 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 já não 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 que 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 próximo 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, o consenso social foi formado. Não importa se depende de marketing ou narrativa técnica, porque o resultado em si é mais importante do que o processo.
É verdade que o próprio consenso social é uma extensão da política democrática, e o mundo real confirmou as deficiências da governação democrática. No entanto, o código aberto e a transparência de dados do próprio blockchain reduziram muito o custo do consenso social. Portanto, Web3's Há uma diferença essencial entre "governo pelo homem" e "governo pelo homem" em estados soberanos reais.
Se considerarmos a blockchain em si como um meio técnico para melhorar questões de transparência da informação na governação democrática, em vez de simplesmente perseguir a “Confiança conseguida puramente pelo código” que nunca está ao alcance, tudo parece tornar-se muito mais otimista e claro. Apenas ao livrarmo-nos da arrogância e preconceito inerentes à elite técnica e abraçar uma audiência mais ampla é que o sistema Ethereum Camada 2 pode verdadeiramente tornar-se numa infraestrutura financeira de classe mundial com adoção em massa.