O ecossistema expandiu-se rapidamente no último ano. O ecossistema rollup ZK-EVM, tradicionalmente representado por StarkNet, Arbitrum, Optimism e Scroll, está progredindo rapidamente, melhorando sua segurança, e a página L2beat fornece um bom resumo do status de cada projeto.
Além disso, estamos vendo equipes construindo sidechains e rollups (por exemplo, Polygon), alguns projetos L1 tentando avançar para a validação (por exemplo, Celo) e tentativas completamente novas (por exemplo, Linea, Zeth...). ）。
Uma das consequências inevitáveis disso é que vemos que os projetos L2 tendem a ser mais heterogêneos (ou seja, "isomerizados"). Em cripto, "heterogeneidade" refere-se à coexistência ou mistura de diferentes tipos de coisas ou de diferentes naturezas. Este termo é frequentemente usado para descrever diferentes blockchains, protocolos, tecnologias ou ativos que têm características, regras ou atributos diferentes). Espero que esta tendência se mantenha pelas seguintes razões:
Atualmente, vários projetos L1 independentes estão procurando se envolver mais de perto com o ecossistema Ethereum e potencialmente se transformar em projetos L2. Estes projetos podem querer adotar uma abordagem faseada da transição. Fazer uma transição geral imediata reduzirá a usabilidade porque a tecnologia não está pronta para colocar tudo em um cenário de rollup. E na transição geral posterior, pode ser tarde demais para sacrificar o ímpeto e fazer sentido prático.
Alguns projetos centralizados querem fornecer mais segurança aos seus usuários e estão explorando caminhos baseados em blockchain. Em muitos casos, esses projetos podem ter analisado "blockchains de consórcio autorizado" no passado. Na verdade, eles só precisam atingir o nível de "semi-centralização". Além disso, normalmente têm um rendimento muito elevado, o que os torna inadequados para regimes de rollup, pelo menos a curto prazo.
As aplicações não financeiras, como jogos ou redes sociais, querem ser descentralizadas, mas só precisam de um certo nível de segurança.
No caso das redes sociais, existem realmente diferentes partes do aplicativo que são abordadas de maneiras diferentes: atividades raras e de alto valor, como registro de nome de usuário e recuperação de conta, devem ser feitas em um esquema de rollup, mas atividades frequentes e de baixo valor, como postagens e enquetes, exigem menos segurança, o que é um preço aceitável a pagar se o blockchain falhar e fizer com que suas postagens desapareçam; Mas se uma falha de blockchain fizer com que você perca sua conta, isso é um problema maior.
Um tema importante é que, enquanto os aplicativos e usuários atualmente localizados no Ethereum L1 estão dispostos a pagar taxas de rollup menores, mas ainda visíveis, no curto prazo, os usuários do mundo não-blockchain estão menos dispostos a fazê-lo: se você já pagou $1, então pagar $0.10 é mais aceitável, e se você já pagou $0, é difícil aceitar.
Isso se aplica a aplicativos que ainda são centralizados hoje, bem como projetos L1 menores que geralmente têm taxas extremamente baixas quando sua base de usuários é pequena.
Uma pergunta natural é: qual desses compromissos complexos entre esquemas de rollup, validiums e outros sistemas é razoável para uma aplicação específica?
Rollups vs Validiums vs Desconectados s
A primeira dimensão de segurança e escalabilidade que exploraremos pode ser descrita da seguinte forma: Se você possui um ativo que é emitido em L1, em seguida, depositá-lo em L2 e, em seguida, transferi-lo para você, quanta garantia você tem de que você pode obter o ativo de volta para L1?
Há também uma questão relacionada: que escolha de tecnologia leva a esse nível de garantia e quais são as compensações dessa escolha de tecnologia?
Podemos ilustrar o problema com um diagrama simples:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
Vale ressaltar que este é um cenário simplificado em que existem muitas opções intermediárias. Por exemplo:
Entre rollup e validium: No validium, qualquer pessoa pode fazer um pagamento on-chain para cobrir as taxas de transação, momento em que o operador será forçado a fornecer alguns dados para a cadeia ou perder o depósito.
Entre plasma e validium: um sistema de plasma fornece garantias de segurança semelhantes a rollup com disponibilidade de dados off-chain, mas suporta apenas um número limitado de aplicações. Um sistema pode fornecer um EVM completo com garantias de nível de plasma para aqueles que não usam essas aplicações mais complexas, bem como garantias de nível de validade para aqueles que usam essas aplicações.
Essas opções intermediárias podem ser pensadas como um espectro entre o rollup e o validium. Mas o que motiva a candidatura a escolher um ponto específico nesse espectro, em vez de um ponto mais à esquerda ou à direita? Aqui, há dois fatores principais:
**1. O custo da disponibilidade de dados nativos do Ethereum, que diminuirá com o tempo à medida que a tecnologia evolui. O próximo hard fork do Ethereum, Dencun, apresenta o EIP-4844 (também conhecido como "proto-danksharding"), que fornece aproximadamente 32 kB/s de disponibilidade de dados on-chain.
Espera-se que essa disponibilidade de dados aumente gradualmente nos próximos anos com a implantação completa do danksharding, com o objetivo final de cerca de 1,3 MB/s de disponibilidade de dados. Ao mesmo tempo, melhorias na compressão de dados nos permitirão fazer mais com a mesma quantidade de dados.
**2. As próprias necessidades do aplicativo: Qual é a gravidade da perda do usuário em termos de altos custos em relação ao problema com o aplicativo? ** As aplicações financeiras perderão mais devido ao insucesso da candidatura; Os jogos e as redes sociais envolvem muita atividade do utilizador e atividades de valor relativamente baixo, pelo que diferentes compensações de segurança fazem sentido para eles.
Este trade-off é mais ou menos assim:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
Outro tipo que vale a pena mencionar são as pré-confirmações. Uma pré-confirmação é uma mensagem assinada por um grupo de participantes em um rollup ou validium que diz "provamos que essas transações estão incluídas nesta ordem e que a raiz pós-estado é esta". Estes participantes podem assinar uma pré-confirmação que não corresponde à realidade, mas se o fizer, os seus depósitos serão destruídos.
Isso é útil para aplicativos de baixo valor, como pagamentos de consumidores, enquanto aplicativos de alto valor, como transferências financeiras multimilionárias, podem esperar por uma confirmação "regular" apoiada pela integridade da segurança do sistema.
A pré-confirmação pode ser vista como outro exemplo de um sistema híbrido, semelhante ao "híbrido plasma/validium" mencionado acima, mas desta vez entre um rollup (ou validium) com segurança total, mas alta latência e um sistema com um nível mais baixo de segurança, mas baixa latência. Os aplicativos que exigem menor latência receberão menor segurança, mas podem coexistir no mesmo ecossistema daqueles que estão dispostos a tolerar latência mais alta para máxima segurança.
Leitura sem confiança do Ethereum
Outra forma de conexão que é menos considerada, mas ainda muito importante, tem a ver com a capacidade do sistema de ler o blockchain Ethereum. Especificamente, isso inclui a capacidade do sistema de reverter quando o Ethereum ocorre. Para entender por que isso é valioso, considere o seguinte cenário:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
Digamos que ocorra uma reversão no blockchain Ethereum, como mostrado no diagrama. Isso pode ser uma interrupção temporária dentro de uma época em que o blockchain ainda não foi finalizado; Ou pode ser porque muitos validadores estão offline, resultando em períodos de vazamento inativos que o blockchain não pode finalizar por um longo período de tempo.
O pior cenário que pode resultar disso é o seguinte: Suponha que o primeiro bloco da cadeia superior leia alguns dados do bloco mais à esquerda da cadeia Ethereum. Por exemplo, alguém deposita 100 ETH no Ethereum na cadeia superior. Em seguida, o Ethereum reverteu, mas a cadeia de topo não. Como resultado, os futuros blocos na cadeia superior seguem corretamente os novos blocos corretos na blockchain Ethereum, mas a transação errada (ou seja, um depósito de 100 ETH) ainda existe na cadeia superior. Esta vulnerabilidade pode levar a uma emissão adicional de moedas, transformando ETH em ponte na cadeia superior em reservas parciais.
Existem duas formas de resolver este problema:
A cadeia superior só pode ler blocos que foram finalizados pelo Ethereum, por isso nunca precisa ser revertido;
Se ocorrer uma reversão no Ethereum, uma reversão também pode ocorrer na cadeia superior. Ambos podem evitar esse problema. O primeiro é mais fácil de implementar, mas se o Ethereum entrar em um período de vazamento inativo, pode levar a uma perda de funcionalidade por um longo período de tempo. Este último é mais difícil de implementar, mas garante que tem sempre as melhores características.
Note-se que existe, de facto, um caso especial para o primeiro método. Se houver um ataque de 51% ao Ethereum, resultando em dois novos blocos incompatíveis aparecendo ao mesmo tempo, ambos parecem ter sido finalizados, então a cadeia superior pode escolher o bloco errado (ou seja, o bloco que o consenso social Ethereum em última análise não suporta) e precisa reverter para mudar para o bloco correto. Indiscutivelmente, não é necessário escrever código de antemão para lidar com esta situação; Isso pode ser manuseado fazendo um hard fork da cadeia superior.
Há duas razões importantes para a capacidade do blockchain de ler o Ethereum sem confiança:
Primeiro, essa capacidade pode reduzir os problemas de segurança envolvidos na ponte entre tokens emitidos no Ethereum (ou outras soluções de camada 2) para essa cadeia;
Em segundo lugar, esse recurso permite carteiras de abstração de conta que usam uma estrutura de armazenamento de chaves compartilhadas para manter ativos seguros na cadeia.
Apesar da controvérsia, a importância da primeira abordagem é amplamente reconhecida. Mais uma vez, o segundo método é importante porque significa que você pode ter uma carteira que pode facilmente mudar chaves e manter ativos em muitas cadeias diferentes.
Ter uma ponte faz valer?
Digamos que a cadeia de topo foi inicialmente lançada como uma cadeia independente, e depois alguém implantou um contrato de ponte no Ethereum. Um contrato de ponte é simplesmente um contrato que aceita cabeçalhos de bloco da cadeia superior, verificando se todos os cabeçalhos de bloco enviados a ele são acompanhados por um certificado válido que prova que o cabeçalho de bloco foi aceito pelo consenso da cadeia superior e adiciona o cabeçalho de bloco à lista.
O aplicativo pode criar recursos em cima disso, como o depósito e retirada de tokens. Uma vez estabelecida essa ponte, ela fornece alguma das garantias de segurança patrimonial que mencionamos anteriormente?
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
Até agora, ainda não! Há duas razões para isso:
Estamos verificando a assinatura do bloco, mas não estamos verificando se a transição de estado está correta. Assim, se você depositar ativos emitidos no Ethereum na cadeia superior, e o validador da cadeia superior se tornar desonesto, eles podem assinar uma transição de estado inválida, roubando assim esses ativos;
A cadeia superior ainda é ilegível Ethereum. Como resultado, você não pode depositar ativos nativos do Ethereum na cadeia superior, a menos que dependa de outras (e potencialmente inseguras) pontes de terceiros.
Agora, vamos construir a ponte como uma ponte validadora: ela não apenas verifica o consenso, mas também verifica se o estado de qualquer novo bloco calculado usando provas ZK-SNARK está correto.
Uma vez concluída esta etapa, os validadores na cadeia superior não serão capazes de roubar seus fundos. Podem publicar um bloco contendo dados inutilizáveis, impedindo que todos retirem fundos, mas não podem roubar os fundos (a menos que tentem revelar os dados que permitem aos utilizadores levantar os seus fundos exigindo um resgate). Este tem o mesmo modelo de segurança que os validiums.
No entanto, ainda não resolvemos o segundo problema: a cadeia superior não consegue ler os dados do Ethereum. Para o conseguir, temos de fazer uma de duas coisas:
Coloque um contrato de ponte na cadeia superior que valide o bloco Ethereum finalizado;
Inclua um hash do bloco Ethereum mais recente em cada bloco da cadeia superior e empregue regras de seleção de fork para impor o link de hash. Ou seja, o próprio bloco top-chain que será vinculado a um bloco Ethereum em uma cadeia não-principal é não-mainchain. Se o bloco Ethereum conectado ao blockchain de cadeia superior está inicialmente na cadeia principal, mas depois se torna não-mainchain, o bloco de cadeia superior também deve se tornar não-mainchain.
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
Esses links roxos podem ser hash links ou contratos bridge que verificam o consenso Ethereum
Isso é suficiente? Na verdade, não é suficiente, porque existem alguns pequenos casos de borda:
O que acontece se o Ethereum sofrer um ataque de 51%?
Como lidar com a atualização do hard fork do Ethereum?
Como lidar com uma atualização de hard fork da sua corrente?
Um ataque de 51% ao Ethereum teria consequências semelhantes a um ataque de 51% na cadeia superior, mas o oposto seria verdadeiro. Um hard fork do Ethereum poderia invalidar a ponte Ethereum dentro da cadeia superior. Um compromisso social, ou seja, se o Ethereum restaurar um bloco finalizado, ele será restaurado, e se o Ethereum fizer um hard fork, será hard forked, é a maneira mais limpa de resolver esse problema.
Tal promessa pode nunca precisar ser realmente cumprida: se o órgão de governança da cadeia superior encontrar evidências de um possível ataque ou hard fork, ele pode ativar o órgão de governança e apenas hard fork a cadeia superior se o órgão de governança falhar.
Para a terceira pergunta, a única resposta viável é ter alguma forma de governança no Ethereum que tornaria o contrato ponte no Ethereum ciente da atualização do hard fork da cadeia superior.
Resumo: Uma ponte de verificação bidirecional é quase suficiente para tornar um blockchain válido. O principal elemento restante é um compromisso social de que, se algo incomum acontecer com o Ethereum que faça com que o contrato ponte não funcione corretamente, outro blockchain fará um hard fork em resposta.
Conclusão
"Conectando-se com Ethereum" tem duas dimensões-chave:
Segurança dos levantamentos para Ethereum;
Leia a segurança do Ethereum.
Ambos são muito importantes e têm considerações diferentes. Em ambos os casos, há um continuum:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
Observe que cada dimensão é medida de duas maneiras diferentes (na verdade, existem quatro): a segurança extraída pode ser medida por (i) o nível de segurança e (ii) quantos usuários ou usuários se beneficiam do mais alto nível de segurança;
A segurança de leitura pode ser medida por (i) quão rápido o link pode ler os blocos do Ethereum e, em particular, como o bloco finalizado difere de qualquer bloco, e (ii) quão comprometido o link é ao lidar com casos de borda, como ataques de 51% e hard forks.
Há valor para o projeto em muitas áreas deste espaço de design. Para algumas aplicações, um alto nível de segurança e conectividade rígida são essenciais. Para outras aplicações, condições mais brandas são aceitáveis para maior escalabilidade. Em muitos casos, começando com condições mais frouxas hoje, uma transição gradual para um acoplamento mais rígido ao longo da próxima década pode ser ideal à medida que a tecnologia melhora.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2
Título Original: "Diferentes tipos de camada 2s"
Palavras: Vitalik Buterin
Compilação: BlockBeats
O ecossistema expandiu-se rapidamente no último ano. O ecossistema rollup ZK-EVM, tradicionalmente representado por StarkNet, Arbitrum, Optimism e Scroll, está progredindo rapidamente, melhorando sua segurança, e a página L2beat fornece um bom resumo do status de cada projeto.
Além disso, estamos vendo equipes construindo sidechains e rollups (por exemplo, Polygon), alguns projetos L1 tentando avançar para a validação (por exemplo, Celo) e tentativas completamente novas (por exemplo, Linea, Zeth...). ）。
Uma das consequências inevitáveis disso é que vemos que os projetos L2 tendem a ser mais heterogêneos (ou seja, "isomerizados"). Em cripto, "heterogeneidade" refere-se à coexistência ou mistura de diferentes tipos de coisas ou de diferentes naturezas. Este termo é frequentemente usado para descrever diferentes blockchains, protocolos, tecnologias ou ativos que têm características, regras ou atributos diferentes). Espero que esta tendência se mantenha pelas seguintes razões:
Atualmente, vários projetos L1 independentes estão procurando se envolver mais de perto com o ecossistema Ethereum e potencialmente se transformar em projetos L2. Estes projetos podem querer adotar uma abordagem faseada da transição. Fazer uma transição geral imediata reduzirá a usabilidade porque a tecnologia não está pronta para colocar tudo em um cenário de rollup. E na transição geral posterior, pode ser tarde demais para sacrificar o ímpeto e fazer sentido prático.
Alguns projetos centralizados querem fornecer mais segurança aos seus usuários e estão explorando caminhos baseados em blockchain. Em muitos casos, esses projetos podem ter analisado "blockchains de consórcio autorizado" no passado. Na verdade, eles só precisam atingir o nível de "semi-centralização". Além disso, normalmente têm um rendimento muito elevado, o que os torna inadequados para regimes de rollup, pelo menos a curto prazo.
As aplicações não financeiras, como jogos ou redes sociais, querem ser descentralizadas, mas só precisam de um certo nível de segurança.
No caso das redes sociais, existem realmente diferentes partes do aplicativo que são abordadas de maneiras diferentes: atividades raras e de alto valor, como registro de nome de usuário e recuperação de conta, devem ser feitas em um esquema de rollup, mas atividades frequentes e de baixo valor, como postagens e enquetes, exigem menos segurança, o que é um preço aceitável a pagar se o blockchain falhar e fizer com que suas postagens desapareçam; Mas se uma falha de blockchain fizer com que você perca sua conta, isso é um problema maior.
Um tema importante é que, enquanto os aplicativos e usuários atualmente localizados no Ethereum L1 estão dispostos a pagar taxas de rollup menores, mas ainda visíveis, no curto prazo, os usuários do mundo não-blockchain estão menos dispostos a fazê-lo: se você já pagou $1, então pagar $0.10 é mais aceitável, e se você já pagou $0, é difícil aceitar.
Isso se aplica a aplicativos que ainda são centralizados hoje, bem como projetos L1 menores que geralmente têm taxas extremamente baixas quando sua base de usuários é pequena.
Uma pergunta natural é: qual desses compromissos complexos entre esquemas de rollup, validiums e outros sistemas é razoável para uma aplicação específica?
Rollups vs Validiums vs Desconectados s
A primeira dimensão de segurança e escalabilidade que exploraremos pode ser descrita da seguinte forma: Se você possui um ativo que é emitido em L1, em seguida, depositá-lo em L2 e, em seguida, transferi-lo para você, quanta garantia você tem de que você pode obter o ativo de volta para L1?
Há também uma questão relacionada: que escolha de tecnologia leva a esse nível de garantia e quais são as compensações dessa escolha de tecnologia?
Podemos ilustrar o problema com um diagrama simples:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
Vale ressaltar que este é um cenário simplificado em que existem muitas opções intermediárias. Por exemplo:
Entre rollup e validium: No validium, qualquer pessoa pode fazer um pagamento on-chain para cobrir as taxas de transação, momento em que o operador será forçado a fornecer alguns dados para a cadeia ou perder o depósito.
Entre plasma e validium: um sistema de plasma fornece garantias de segurança semelhantes a rollup com disponibilidade de dados off-chain, mas suporta apenas um número limitado de aplicações. Um sistema pode fornecer um EVM completo com garantias de nível de plasma para aqueles que não usam essas aplicações mais complexas, bem como garantias de nível de validade para aqueles que usam essas aplicações.
Essas opções intermediárias podem ser pensadas como um espectro entre o rollup e o validium. Mas o que motiva a candidatura a escolher um ponto específico nesse espectro, em vez de um ponto mais à esquerda ou à direita? Aqui, há dois fatores principais:
**1. O custo da disponibilidade de dados nativos do Ethereum, que diminuirá com o tempo à medida que a tecnologia evolui. O próximo hard fork do Ethereum, Dencun, apresenta o EIP-4844 (também conhecido como "proto-danksharding"), que fornece aproximadamente 32 kB/s de disponibilidade de dados on-chain.
Espera-se que essa disponibilidade de dados aumente gradualmente nos próximos anos com a implantação completa do danksharding, com o objetivo final de cerca de 1,3 MB/s de disponibilidade de dados. Ao mesmo tempo, melhorias na compressão de dados nos permitirão fazer mais com a mesma quantidade de dados.
**2. As próprias necessidades do aplicativo: Qual é a gravidade da perda do usuário em termos de altos custos em relação ao problema com o aplicativo? ** As aplicações financeiras perderão mais devido ao insucesso da candidatura; Os jogos e as redes sociais envolvem muita atividade do utilizador e atividades de valor relativamente baixo, pelo que diferentes compensações de segurança fazem sentido para eles.
Este trade-off é mais ou menos assim:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
Outro tipo que vale a pena mencionar são as pré-confirmações. Uma pré-confirmação é uma mensagem assinada por um grupo de participantes em um rollup ou validium que diz "provamos que essas transações estão incluídas nesta ordem e que a raiz pós-estado é esta". Estes participantes podem assinar uma pré-confirmação que não corresponde à realidade, mas se o fizer, os seus depósitos serão destruídos.
Isso é útil para aplicativos de baixo valor, como pagamentos de consumidores, enquanto aplicativos de alto valor, como transferências financeiras multimilionárias, podem esperar por uma confirmação "regular" apoiada pela integridade da segurança do sistema.
A pré-confirmação pode ser vista como outro exemplo de um sistema híbrido, semelhante ao "híbrido plasma/validium" mencionado acima, mas desta vez entre um rollup (ou validium) com segurança total, mas alta latência e um sistema com um nível mais baixo de segurança, mas baixa latência. Os aplicativos que exigem menor latência receberão menor segurança, mas podem coexistir no mesmo ecossistema daqueles que estão dispostos a tolerar latência mais alta para máxima segurança.
Leitura sem confiança do Ethereum
Outra forma de conexão que é menos considerada, mas ainda muito importante, tem a ver com a capacidade do sistema de ler o blockchain Ethereum. Especificamente, isso inclui a capacidade do sistema de reverter quando o Ethereum ocorre. Para entender por que isso é valioso, considere o seguinte cenário:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
Digamos que ocorra uma reversão no blockchain Ethereum, como mostrado no diagrama. Isso pode ser uma interrupção temporária dentro de uma época em que o blockchain ainda não foi finalizado; Ou pode ser porque muitos validadores estão offline, resultando em períodos de vazamento inativos que o blockchain não pode finalizar por um longo período de tempo.
O pior cenário que pode resultar disso é o seguinte: Suponha que o primeiro bloco da cadeia superior leia alguns dados do bloco mais à esquerda da cadeia Ethereum. Por exemplo, alguém deposita 100 ETH no Ethereum na cadeia superior. Em seguida, o Ethereum reverteu, mas a cadeia de topo não. Como resultado, os futuros blocos na cadeia superior seguem corretamente os novos blocos corretos na blockchain Ethereum, mas a transação errada (ou seja, um depósito de 100 ETH) ainda existe na cadeia superior. Esta vulnerabilidade pode levar a uma emissão adicional de moedas, transformando ETH em ponte na cadeia superior em reservas parciais.
Existem duas formas de resolver este problema:
A cadeia superior só pode ler blocos que foram finalizados pelo Ethereum, por isso nunca precisa ser revertido;
Se ocorrer uma reversão no Ethereum, uma reversão também pode ocorrer na cadeia superior. Ambos podem evitar esse problema. O primeiro é mais fácil de implementar, mas se o Ethereum entrar em um período de vazamento inativo, pode levar a uma perda de funcionalidade por um longo período de tempo. Este último é mais difícil de implementar, mas garante que tem sempre as melhores características.
Note-se que existe, de facto, um caso especial para o primeiro método. Se houver um ataque de 51% ao Ethereum, resultando em dois novos blocos incompatíveis aparecendo ao mesmo tempo, ambos parecem ter sido finalizados, então a cadeia superior pode escolher o bloco errado (ou seja, o bloco que o consenso social Ethereum em última análise não suporta) e precisa reverter para mudar para o bloco correto. Indiscutivelmente, não é necessário escrever código de antemão para lidar com esta situação; Isso pode ser manuseado fazendo um hard fork da cadeia superior.
Há duas razões importantes para a capacidade do blockchain de ler o Ethereum sem confiança:
Primeiro, essa capacidade pode reduzir os problemas de segurança envolvidos na ponte entre tokens emitidos no Ethereum (ou outras soluções de camada 2) para essa cadeia;
Em segundo lugar, esse recurso permite carteiras de abstração de conta que usam uma estrutura de armazenamento de chaves compartilhadas para manter ativos seguros na cadeia.
Apesar da controvérsia, a importância da primeira abordagem é amplamente reconhecida. Mais uma vez, o segundo método é importante porque significa que você pode ter uma carteira que pode facilmente mudar chaves e manter ativos em muitas cadeias diferentes.
Ter uma ponte faz valer?
Digamos que a cadeia de topo foi inicialmente lançada como uma cadeia independente, e depois alguém implantou um contrato de ponte no Ethereum. Um contrato de ponte é simplesmente um contrato que aceita cabeçalhos de bloco da cadeia superior, verificando se todos os cabeçalhos de bloco enviados a ele são acompanhados por um certificado válido que prova que o cabeçalho de bloco foi aceito pelo consenso da cadeia superior e adiciona o cabeçalho de bloco à lista.
O aplicativo pode criar recursos em cima disso, como o depósito e retirada de tokens. Uma vez estabelecida essa ponte, ela fornece alguma das garantias de segurança patrimonial que mencionamos anteriormente?
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
Até agora, ainda não! Há duas razões para isso:
Estamos verificando a assinatura do bloco, mas não estamos verificando se a transição de estado está correta. Assim, se você depositar ativos emitidos no Ethereum na cadeia superior, e o validador da cadeia superior se tornar desonesto, eles podem assinar uma transição de estado inválida, roubando assim esses ativos;
A cadeia superior ainda é ilegível Ethereum. Como resultado, você não pode depositar ativos nativos do Ethereum na cadeia superior, a menos que dependa de outras (e potencialmente inseguras) pontes de terceiros.
Agora, vamos construir a ponte como uma ponte validadora: ela não apenas verifica o consenso, mas também verifica se o estado de qualquer novo bloco calculado usando provas ZK-SNARK está correto.
Uma vez concluída esta etapa, os validadores na cadeia superior não serão capazes de roubar seus fundos. Podem publicar um bloco contendo dados inutilizáveis, impedindo que todos retirem fundos, mas não podem roubar os fundos (a menos que tentem revelar os dados que permitem aos utilizadores levantar os seus fundos exigindo um resgate). Este tem o mesmo modelo de segurança que os validiums.
No entanto, ainda não resolvemos o segundo problema: a cadeia superior não consegue ler os dados do Ethereum. Para o conseguir, temos de fazer uma de duas coisas:
Coloque um contrato de ponte na cadeia superior que valide o bloco Ethereum finalizado;
Inclua um hash do bloco Ethereum mais recente em cada bloco da cadeia superior e empregue regras de seleção de fork para impor o link de hash. Ou seja, o próprio bloco top-chain que será vinculado a um bloco Ethereum em uma cadeia não-principal é não-mainchain. Se o bloco Ethereum conectado ao blockchain de cadeia superior está inicialmente na cadeia principal, mas depois se torna não-mainchain, o bloco de cadeia superior também deve se tornar não-mainchain.
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
Esses links roxos podem ser hash links ou contratos bridge que verificam o consenso Ethereum
Isso é suficiente? Na verdade, não é suficiente, porque existem alguns pequenos casos de borda:
O que acontece se o Ethereum sofrer um ataque de 51%?
Como lidar com a atualização do hard fork do Ethereum?
Como lidar com uma atualização de hard fork da sua corrente?
Um ataque de 51% ao Ethereum teria consequências semelhantes a um ataque de 51% na cadeia superior, mas o oposto seria verdadeiro. Um hard fork do Ethereum poderia invalidar a ponte Ethereum dentro da cadeia superior. Um compromisso social, ou seja, se o Ethereum restaurar um bloco finalizado, ele será restaurado, e se o Ethereum fizer um hard fork, será hard forked, é a maneira mais limpa de resolver esse problema.
Tal promessa pode nunca precisar ser realmente cumprida: se o órgão de governança da cadeia superior encontrar evidências de um possível ataque ou hard fork, ele pode ativar o órgão de governança e apenas hard fork a cadeia superior se o órgão de governança falhar.
Para a terceira pergunta, a única resposta viável é ter alguma forma de governança no Ethereum que tornaria o contrato ponte no Ethereum ciente da atualização do hard fork da cadeia superior.
Resumo: Uma ponte de verificação bidirecional é quase suficiente para tornar um blockchain válido. O principal elemento restante é um compromisso social de que, se algo incomum acontecer com o Ethereum que faça com que o contrato ponte não funcione corretamente, outro blockchain fará um hard fork em resposta.
Conclusão
"Conectando-se com Ethereum" tem duas dimensões-chave:
Segurança dos levantamentos para Ethereum;
Leia a segurança do Ethereum.
Ambos são muito importantes e têm considerações diferentes. Em ambos os casos, há um continuum:
! [Vitalik: É hora de parar com as brigas, tenho algo a dizer sobre a definição de Camada 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
Observe que cada dimensão é medida de duas maneiras diferentes (na verdade, existem quatro): a segurança extraída pode ser medida por (i) o nível de segurança e (ii) quantos usuários ou usuários se beneficiam do mais alto nível de segurança;
A segurança de leitura pode ser medida por (i) quão rápido o link pode ler os blocos do Ethereum e, em particular, como o bloco finalizado difere de qualquer bloco, e (ii) quão comprometido o link é ao lidar com casos de borda, como ataques de 51% e hard forks.
Há valor para o projeto em muitas áreas deste espaço de design. Para algumas aplicações, um alto nível de segurança e conectividade rígida são essenciais. Para outras aplicações, condições mais brandas são aceitáveis para maior escalabilidade. Em muitos casos, começando com condições mais frouxas hoje, uma transição gradual para um acoplamento mais rígido ao longo da próxima década pode ser ideal à medida que a tecnologia melhora.