! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Um agradecimento especial a Karl Floersch pelo feedback e revisão
O ecossistema Ethereum Layer 2 tem se expandido rapidamente no último ano. O ecossistema ZK-EVM Rollup, representado por StarkNet, Arbitrum, Optimism e Scroll, fez grandes progressos na melhoria da segurança, e a página L2beat fornece um bom resumo do status de cada projeto. Além disso, vimos algumas equipes construindo sidechains começando a construir Rollups (Polygon), alguns projetos de Camada 1 tentando migrar para Validation (Celo) e fazendo novos esforços (Linea, Zeth, etc.).
Como resultado, os projetos de camada 2 estão se tornando mais heterogêneos. Espero que esta tendência se mantenha pelas seguintes razões:
Alguns projetos de Camada 1 atualmente autônomos estão buscando se aproximar do ecossistema Ethereum e potencialmente se tornar a Camada 2. **Estes projetos podem exigir uma transição gradual. Mudar agora resultará em uma diminuição na usabilidade porque a tecnologia não está pronta para colocar tudo no rollup; Mas mudar demasiado tarde pode custar ímpeto e é demasiado tarde para fazer qualquer sentido.
Alguns projetos centralizados querem fornecer aos usuários mais garantias de segurança e estão explorando caminhos baseados em blockchain. Em muitos casos, estes projetos podem explorar previamente «cadeias de consórcio autorizadas». Na verdade, eles podem precisar apenas de um nível "intermediário" de descentralização. Além disso, muitas vezes têm um rendimento muito elevado, o que os torna nem sequer adequados para rollups, pelo menos a curto prazo.
As aplicações não financeiras, como os jogos ou as redes sociais, querem ser descentralizadas, mas precisam apenas de uma "camada intermédia" de segurança. As redes sociais, por exemplo, na verdade envolvem diferentes partes do aplicativo sendo tratadas de forma diferente: atividades de baixa frequência e alto valor, como registro de nome de usuário e recuperação de conta, devem ser feitas no Rollup; Atividades de alta frequência e baixo valor, como postagem e votação, exigem menos segurança. Se o seu post desaparecer devido a uma falha em cadeia, esse é um preço aceitável; Mas se a falha da cadeia fizer com que você perca sua conta, isso é um grande problema.
Uma questão importante é que pagar uma taxa de rollup menor, mas ainda visível, é aceitável para aplicativos e usuários da Camada 1 do Ethereum no momento, mas não para usuários fora do mundo blockchain: se você pagou anteriormente $1, então pagar $0.10 é mais aceitável; Mas se você pagou anteriormente $0, então pagar $0.10 é inaceitável. Isso se aplica tanto aos aplicativos centralizados atuais quanto a projetos menores de Camada 1, que geralmente têm taxas muito baixas com uma pequena base de usuários.
A questão que se coloca é: Qual desses compromissos complexos entre rollups, validiums e outros sistemas é razoável para uma aplicação específica?
Rollups、Validiums、Desconectado
A primeira dimensão de segurança e escala que exploraremos pode ser descrita da seguinte forma: Se você possui um ativo que foi emitido na Camada 1 e depois depositado na Camada 2 e depois transferido para sua conta, pode ter certeza de que pode recuperar esse ativo para a Camada 1? **
Ao mesmo tempo, há uma pergunta semelhante: quais são as escolhas tecnológicas que levam a essa garantia e quais são as compensações por trás dessas escolhas tecnológicas? **
Podemos simplesmente descrever o problema usando uma tabela:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Vale ressaltar que esta é uma arquitetura simplificada e há muitos itens intermediários para escolher. Por exemplo:
Entre Rollup e Validium: Um tipo de validium que permite que qualquer pessoa faça pagamentos 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: O sistema Plasma fornece garantias de segurança semelhantes a rollup e disponibilidade de dados off-chain (DA), mas suporta apenas um número limitado de aplicações. Um sistema pode fornecer um EVM completo e fornecer garantias de nível de plasma para usuários que não usam esses aplicativos mais complexos, e garantias de nível de validade para usuários que usam esses aplicativos.
Essas opções intermediárias podem ser vistas como um espectro de tecnologias entre rollups e validiums. Mas o que motiva o aplicativo a escolher um ponto específico no pedigree, em vez da extrema esquerda ou da extrema direita? Há dois fatores principais aqui:
O custo da disponibilidade de dados no próprio Ethereum diminuirá gradualmente à medida que a tecnologia melhorar. O próximo hard fork da Ethereum, Dencun, introduziu o EIP-4844 (também conhecido como "proto-danksharding"), que fornece um DA on-chain de cerca de 32 kB/seg. Ao longo dos próximos anos, espera-se que esse número aumente gradualmente com a implantação completa do danksharding, eventualmente atingindo uma meta de DA de cerca de 1,3 MB/seg. Ao mesmo tempo, melhorias na compressão de dados nos permitirão fazer mais com a mesma quantidade de dados.
As necessidades do aplicativo em si: Quanto o usuário perde devido a altas taxas em comparação com problemas com o aplicativo? ** As aplicações financeiras perdem mais devido a falhas na aplicação; Os jogos e as redes sociais envolvem uma grande quantidade de atividade por utilizador e o valor da atividade é relativamente baixo, pelo que o compromisso entre segurança é diferente para eles.
Este trade-off é mais ou menos assim:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Outra garantia parcial que vale a pena mencionar são as pré-confirmações. Uma pré-confirmação é uma mensagem assinada por alguns 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 posteriormente uma pré-confirmação que não corresponda à situação real; Mas se o fizerem, queimam um depósito. 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" do suporte de segurança total do sistema.
A pré-validação pode ser vista como outro exemplo de um sistema híbrido, semelhante ao "sistema 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 menor de segurança, mas menor latência. Os aplicativos que exigem menor latência obtêm menor segurança, mas podem coexistir no mesmo ecossistema que os aplicativos que exigem maior latência em troca de segurança máxima.
Leia Ethereum sem permissão
Outra forma de conexão menos considerada, mas ainda muito importante, tem a ver com a capacidade do sistema de ler o blockchain Ethereum. Em particular, isso inclui a capacidade de reverter quando o Ethereum precisa reverter. Para entender por que isso é valioso, considere o seguinte cenário:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Suponhamos que, como mostrado no diagrama, ocorra uma reversão na cadeia Ethereum. Isso pode ser uma falha temporária dentro de uma época em que a cadeia não foi finalizada, ou pode ser que a rede estava inativa e muitos validadores estavam offline e a cadeia não foi finalizada por um longo período de tempo.
O pior cenário a que isto pode conduzir é o seguinte. Digamos 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, ocorre uma reversão com o Ethereum. No entanto, não há reversão da cadeia superior. Como resultado, o futuro bloco da cadeia superior seguiu corretamente o novo bloco da nova cadeia Ethereum correta, mas agora o resultado da cadeia antiga errada (ou seja, um depósito de 100 ETH) ainda existe na cadeia superior. Essa vulnerabilidade pode permitir a criação de uma moeda que converta o ETH em ponte na cadeia superior em uma reserva parcial.
Existem duas formas de resolver este problema:
A cadeia superior só pode ler blocos Ethereum que foram finalizados, portanto, não há necessidade de uma operação de reversão. **
Se ocorrer uma reversão no Ethereum, a cadeia superior também pode reverter. **
Ambos podem evitar que isso aconteça. O primeiro é mais fácil de implementar, mas pode levar a uma perda prolongada de funcionalidade se o Ethereum entrar em um período de inatividade. Este último é mais difícil de implementar, mas garante sempre uma funcionalidade ótima.
É importante notar que há um caso especial no primeiro método (1). Se um ataque de 51% cria dois blocos incompatíveis no Ethereum, e ambos os blocos aparecem finalizados ao mesmo tempo, então a cadeia superior pode escolher o bloco errado (ou seja, o bloco que o consenso da comunidade Ethereum não suporta) e deve ser revertido para mudar para o bloco correto. Indiscutivelmente, não há necessidade de escrever código com antecedência para lidar com essa situação; Ele pode lidar com isso fazendo um hard fork da cadeia superior.
A capacidade das cadeias de ler dados no Ethereum sem permissão é valiosa pelos seguintes motivos:
Reduza os problemas de segurança envolvidos ao cruzar tokens de cadeia emitidos no Ethereum (ou outra Camada 2) para essa cadeia.
Permite carteiras de abstração de conta usando uma estrutura de armazenamento de chaves compartilhadas para manter ativos seguros na cadeia.
A primeira razão é importante, embora esta importância possa já ser amplamente reconhecida; E a segunda razão é tão importante, pois significa que você pode ter uma carteira, mudar facilmente as chaves e manter ativos em muitas cadeias diferentes.
Ter uma ponte torna a corrente válida?
Digamos que a cadeia superior começa como uma única cadeia e, em seguida, alguém coloca um contrato de cadeia cruzada no Ethereum. Um contrato de cadeia cruzada é simplesmente um contrato que aceita o cabeçalho de bloco da cadeia superior, verificando se qualquer cabeçalho enviado a ele vem com um certificado válido indicando que é aceito pelo consenso da cadeia superior e adiciona esse cabeçalho à lista. Os aplicativos podem ser construídos em cima disso para habilitar recursos como depósito e retirada de tokens. Uma vez que essa ponte esteja estabelecida, ela fornece alguma das garantias de segurança patrimonial que mencionamos anteriormente?
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
Até agora, ainda não! Há duas razões para isso:
Estamos verificando se o bloco está assinado, mas não estamos verificando se a transição de estado não está correta. Assim, se você emitir ativos no Ethereum que são depositados na cadeia superior, e os validadores da cadeia superior forem desonestos, eles podem assinar uma transição de estado inválida e roubar esses ativos.
Ainda não há como a cadeia superior ler os dados do Ethereum. Como resultado, você não pode nem mesmo depositar ativos nativos do Ethereum na cadeia superior sem depender de outras (e potencialmente inseguras) pontes de terceiros.
Agora, vamos fazer da ponte uma ponte de validação: ela não só verifica o consenso, mas também um ZK-SNARK que prova que o estado de qualquer novo bloco é calculado corretamente.
Uma vez feito isso, os validadores da cadeia de topo não podem mais roubar seus fundos. Eles podem publicar um bloco contendo dados inutilizáveis, impedindo que todos saiam, mas não podem roubá-lo (a menos que tentem extrair um resgate para os usuários em troca de vazamento de dados que lhes permitam sair). Este é 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 Ethereum.
Para fazer isso, precisamos fazer uma de duas coisas:
Coloque o contrato cross-chain que valida o bloco Ethereum final dentro da cadeia superior.
Faça com que cada bloco na topchain contenha o hash do bloco Ethereum mais recente e tenha uma regra de escolha de fork que imponha o link hash. Ou seja, o bloco top-chain ligado a um bloco Ethereum que não está na cadeia canônica é em si não-canônico, e se o blockchain top-chain está conectado a um bloco Ethereum que inicialmente era canônico, mas depois se torna não-canônico, então o bloco top-chain também deve se tornar não-canônico.
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
O link roxo no diagrama pode ser um link hash ou um contrato bridge que verifica o consenso Ethereum.
Isso é suficiente? Como se viu, não foi suficiente, porque havia alguns pequenos casos especiais:
O que acontece se o Ethereum for atacado por 51%? **
Como lidar com uma atualização de hard fork Ethereum? **
Como lidar com uma atualização de hard fork da cadeia superior?**
O ataque de 51% do Ethereum teria consequências semelhantes ao ataque de 51% da cadeia de topo, mas na direção oposta. Um hard fork do Ethereum pode fazer com que a ponte Ethereum dentro da cadeia superior não seja mais válida. A solução mais limpa para este problema é prometer que, se o Ethereum reverter um bloco finalizado, a cadeia superior também reverterá, e se o Ethereum fizer um hard fork, a cadeia superior também fará um hard fork. Tal promessa pode nunca precisar ser realmente cumprida: você pode ativar um mecanismo de governança na cadeia superior e se ela vir evidências de um possível ataque ou hard fork, e só fazer um hard fork na cadeia superior se o mecanismo de governança falhar.
A única resposta viável para a pergunta (3) é que ter algum tipo de mecanismo de governança no Ethereum tornaria o contrato ponte no Ethereum ciente da atualização do hard fork da cadeia superior.
Resumo: Uma ponte de validação bidirecional é quase suficiente para tornar a cadeia um validium. A principal questão restante é que a outra cadeia fará um compromisso social com um hard fork quando algo acontecer com o Ethereum que faça com que a ponte não funcione.
Conclusão
Existem duas dimensões-chave para a "conexão com o Ethereum":
Segurança dos levantamentos para EthereumSegurança de leitura de dados Ethereum
Ambas as dimensões são importantes e têm considerações diferentes. Em ambos os casos, existe um pedigree:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Note que cada dimensão é medida de duas maneiras diferentes (então existem realmente quatro dimensões?). ): A segurança de extração pode ser medida por (i) o nível de segurança e (ii) a porcentagem de usuários ou casos de uso que se beneficiam do mais alto nível de segurança, enquanto a segurança de leitura pode ser medida por (i) o link ser capaz de ler rapidamente os blocos do Ethereum, especificamente a diferença entre um bloco que foi finalizado e qualquer bloco, e (ii) a força do compromisso social do link ao lidar com casos de borda, como ataques de 51% e hard forks.
São muitos os projetos que têm valor neste espaço de design. Para algumas aplicações, alta segurança e conectividade estreita são importantes. Para outros aplicativos, alguma conectividade mais flexível é aceitável para maior escalabilidade. Em muitos casos, pode ser melhor começar com alguns dos métodos mais brandos atuais e fazer a transição gradual para conexões mais estreitas ao longo da próxima década, à 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.
Papa Vitalinck I redefine L2
Autor original | Vitalik.eth
Compilação | Odaily 0xAyA
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Um agradecimento especial a Karl Floersch pelo feedback e revisão
O ecossistema Ethereum Layer 2 tem se expandido rapidamente no último ano. O ecossistema ZK-EVM Rollup, representado por StarkNet, Arbitrum, Optimism e Scroll, fez grandes progressos na melhoria da segurança, e a página L2beat fornece um bom resumo do status de cada projeto. Além disso, vimos algumas equipes construindo sidechains começando a construir Rollups (Polygon), alguns projetos de Camada 1 tentando migrar para Validation (Celo) e fazendo novos esforços (Linea, Zeth, etc.).
Como resultado, os projetos de camada 2 estão se tornando mais heterogêneos. Espero que esta tendência se mantenha pelas seguintes razões:
Alguns projetos de Camada 1 atualmente autônomos estão buscando se aproximar do ecossistema Ethereum e potencialmente se tornar a Camada 2. **Estes projetos podem exigir uma transição gradual. Mudar agora resultará em uma diminuição na usabilidade porque a tecnologia não está pronta para colocar tudo no rollup; Mas mudar demasiado tarde pode custar ímpeto e é demasiado tarde para fazer qualquer sentido. Alguns projetos centralizados querem fornecer aos usuários mais garantias de segurança e estão explorando caminhos baseados em blockchain. Em muitos casos, estes projetos podem explorar previamente «cadeias de consórcio autorizadas». Na verdade, eles podem precisar apenas de um nível "intermediário" de descentralização. Além disso, muitas vezes têm um rendimento muito elevado, o que os torna nem sequer adequados para rollups, pelo menos a curto prazo. As aplicações não financeiras, como os jogos ou as redes sociais, querem ser descentralizadas, mas precisam apenas de uma "camada intermédia" de segurança. As redes sociais, por exemplo, na verdade envolvem diferentes partes do aplicativo sendo tratadas de forma diferente: atividades de baixa frequência e alto valor, como registro de nome de usuário e recuperação de conta, devem ser feitas no Rollup; Atividades de alta frequência e baixo valor, como postagem e votação, exigem menos segurança. Se o seu post desaparecer devido a uma falha em cadeia, esse é um preço aceitável; Mas se a falha da cadeia fizer com que você perca sua conta, isso é um grande problema.
Uma questão importante é que pagar uma taxa de rollup menor, mas ainda visível, é aceitável para aplicativos e usuários da Camada 1 do Ethereum no momento, mas não para usuários fora do mundo blockchain: se você pagou anteriormente $1, então pagar $0.10 é mais aceitável; Mas se você pagou anteriormente $0, então pagar $0.10 é inaceitável. Isso se aplica tanto aos aplicativos centralizados atuais quanto a projetos menores de Camada 1, que geralmente têm taxas muito baixas com uma pequena base de usuários.
A questão que se coloca é: Qual desses compromissos complexos entre rollups, validiums e outros sistemas é razoável para uma aplicação específica?
Rollups、Validiums、Desconectado
A primeira dimensão de segurança e escala que exploraremos pode ser descrita da seguinte forma: Se você possui um ativo que foi emitido na Camada 1 e depois depositado na Camada 2 e depois transferido para sua conta, pode ter certeza de que pode recuperar esse ativo para a Camada 1? **
Ao mesmo tempo, há uma pergunta semelhante: quais são as escolhas tecnológicas que levam a essa garantia e quais são as compensações por trás dessas escolhas tecnológicas? **
Podemos simplesmente descrever o problema usando uma tabela:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Vale ressaltar que esta é uma arquitetura simplificada e há muitos itens intermediários para escolher. Por exemplo:
Essas opções intermediárias podem ser vistas como um espectro de tecnologias entre rollups e validiums. Mas o que motiva o aplicativo a escolher um ponto específico no pedigree, em vez da extrema esquerda ou da extrema direita? Há dois fatores principais aqui:
O custo da disponibilidade de dados no próprio Ethereum diminuirá gradualmente à medida que a tecnologia melhorar. O próximo hard fork da Ethereum, Dencun, introduziu o EIP-4844 (também conhecido como "proto-danksharding"), que fornece um DA on-chain de cerca de 32 kB/seg. Ao longo dos próximos anos, espera-se que esse número aumente gradualmente com a implantação completa do danksharding, eventualmente atingindo uma meta de DA de cerca de 1,3 MB/seg. Ao mesmo tempo, melhorias na compressão de dados nos permitirão fazer mais com a mesma quantidade de dados. As necessidades do aplicativo em si: Quanto o usuário perde devido a altas taxas em comparação com problemas com o aplicativo? ** As aplicações financeiras perdem mais devido a falhas na aplicação; Os jogos e as redes sociais envolvem uma grande quantidade de atividade por utilizador e o valor da atividade é relativamente baixo, pelo que o compromisso entre segurança é diferente para eles.
Este trade-off é mais ou menos assim:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Outra garantia parcial que vale a pena mencionar são as pré-confirmações. Uma pré-confirmação é uma mensagem assinada por alguns 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 posteriormente uma pré-confirmação que não corresponda à situação real; Mas se o fizerem, queimam um depósito. 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" do suporte de segurança total do sistema.
A pré-validação pode ser vista como outro exemplo de um sistema híbrido, semelhante ao "sistema 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 menor de segurança, mas menor latência. Os aplicativos que exigem menor latência obtêm menor segurança, mas podem coexistir no mesmo ecossistema que os aplicativos que exigem maior latência em troca de segurança máxima.
Leia Ethereum sem permissão
Outra forma de conexão menos considerada, mas ainda muito importante, tem a ver com a capacidade do sistema de ler o blockchain Ethereum. Em particular, isso inclui a capacidade de reverter quando o Ethereum precisa reverter. Para entender por que isso é valioso, considere o seguinte cenário:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Suponhamos que, como mostrado no diagrama, ocorra uma reversão na cadeia Ethereum. Isso pode ser uma falha temporária dentro de uma época em que a cadeia não foi finalizada, ou pode ser que a rede estava inativa e muitos validadores estavam offline e a cadeia não foi finalizada por um longo período de tempo.
O pior cenário a que isto pode conduzir é o seguinte. Digamos 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, ocorre uma reversão com o Ethereum. No entanto, não há reversão da cadeia superior. Como resultado, o futuro bloco da cadeia superior seguiu corretamente o novo bloco da nova cadeia Ethereum correta, mas agora o resultado da cadeia antiga errada (ou seja, um depósito de 100 ETH) ainda existe na cadeia superior. Essa vulnerabilidade pode permitir a criação de uma moeda que converta o ETH em ponte na cadeia superior em uma reserva parcial.
Existem duas formas de resolver este problema:
A cadeia superior só pode ler blocos Ethereum que foram finalizados, portanto, não há necessidade de uma operação de reversão. ** Se ocorrer uma reversão no Ethereum, a cadeia superior também pode reverter. **
Ambos podem evitar que isso aconteça. O primeiro é mais fácil de implementar, mas pode levar a uma perda prolongada de funcionalidade se o Ethereum entrar em um período de inatividade. Este último é mais difícil de implementar, mas garante sempre uma funcionalidade ótima.
É importante notar que há um caso especial no primeiro método (1). Se um ataque de 51% cria dois blocos incompatíveis no Ethereum, e ambos os blocos aparecem finalizados ao mesmo tempo, então a cadeia superior pode escolher o bloco errado (ou seja, o bloco que o consenso da comunidade Ethereum não suporta) e deve ser revertido para mudar para o bloco correto. Indiscutivelmente, não há necessidade de escrever código com antecedência para lidar com essa situação; Ele pode lidar com isso fazendo um hard fork da cadeia superior.
A capacidade das cadeias de ler dados no Ethereum sem permissão é valiosa pelos seguintes motivos:
A primeira razão é importante, embora esta importância possa já ser amplamente reconhecida; E a segunda razão é tão importante, pois significa que você pode ter uma carteira, mudar facilmente as chaves e manter ativos em muitas cadeias diferentes.
Ter uma ponte torna a corrente válida?
Digamos que a cadeia superior começa como uma única cadeia e, em seguida, alguém coloca um contrato de cadeia cruzada no Ethereum. Um contrato de cadeia cruzada é simplesmente um contrato que aceita o cabeçalho de bloco da cadeia superior, verificando se qualquer cabeçalho enviado a ele vem com um certificado válido indicando que é aceito pelo consenso da cadeia superior e adiciona esse cabeçalho à lista. Os aplicativos podem ser construídos em cima disso para habilitar recursos como depósito e retirada de tokens. Uma vez que essa ponte esteja estabelecida, ela fornece alguma das garantias de segurança patrimonial que mencionamos anteriormente?
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
Até agora, ainda não! Há duas razões para isso:
Estamos verificando se o bloco está assinado, mas não estamos verificando se a transição de estado não está correta. Assim, se você emitir ativos no Ethereum que são depositados na cadeia superior, e os validadores da cadeia superior forem desonestos, eles podem assinar uma transição de estado inválida e roubar esses ativos.
Agora, vamos fazer da ponte uma ponte de validação: ela não só verifica o consenso, mas também um ZK-SNARK que prova que o estado de qualquer novo bloco é calculado corretamente.
Uma vez feito isso, os validadores da cadeia de topo não podem mais roubar seus fundos. Eles podem publicar um bloco contendo dados inutilizáveis, impedindo que todos saiam, mas não podem roubá-lo (a menos que tentem extrair um resgate para os usuários em troca de vazamento de dados que lhes permitam sair). Este é 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 Ethereum.
Para fazer isso, precisamos fazer uma de duas coisas:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
O link roxo no diagrama pode ser um link hash ou um contrato bridge que verifica o consenso Ethereum.
Isso é suficiente? Como se viu, não foi suficiente, porque havia alguns pequenos casos especiais:
O que acontece se o Ethereum for atacado por 51%? ** Como lidar com uma atualização de hard fork Ethereum? ** Como lidar com uma atualização de hard fork da cadeia superior?**
O ataque de 51% do Ethereum teria consequências semelhantes ao ataque de 51% da cadeia de topo, mas na direção oposta. Um hard fork do Ethereum pode fazer com que a ponte Ethereum dentro da cadeia superior não seja mais válida. A solução mais limpa para este problema é prometer que, se o Ethereum reverter um bloco finalizado, a cadeia superior também reverterá, e se o Ethereum fizer um hard fork, a cadeia superior também fará um hard fork. Tal promessa pode nunca precisar ser realmente cumprida: você pode ativar um mecanismo de governança na cadeia superior e se ela vir evidências de um possível ataque ou hard fork, e só fazer um hard fork na cadeia superior se o mecanismo de governança falhar.
A única resposta viável para a pergunta (3) é que ter algum tipo de mecanismo de governança no Ethereum tornaria o contrato ponte no Ethereum ciente da atualização do hard fork da cadeia superior.
Resumo: Uma ponte de validação bidirecional é quase suficiente para tornar a cadeia um validium. A principal questão restante é que a outra cadeia fará um compromisso social com um hard fork quando algo acontecer com o Ethereum que faça com que a ponte não funcione.
Conclusão
Existem duas dimensões-chave para a "conexão com o Ethereum":
Segurança dos levantamentos para Ethereum Segurança de leitura de dados Ethereum
Ambas as dimensões são importantes e têm considerações diferentes. Em ambos os casos, existe um pedigree:
! [Papa Vitalinck I redefine L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Note que cada dimensão é medida de duas maneiras diferentes (então existem realmente quatro dimensões?). ): A segurança de extração pode ser medida por (i) o nível de segurança e (ii) a porcentagem de usuários ou casos de uso que se beneficiam do mais alto nível de segurança, enquanto a segurança de leitura pode ser medida por (i) o link ser capaz de ler rapidamente os blocos do Ethereum, especificamente a diferença entre um bloco que foi finalizado e qualquer bloco, e (ii) a força do compromisso social do link ao lidar com casos de borda, como ataques de 51% e hard forks.
São muitos os projetos que têm valor neste espaço de design. Para algumas aplicações, alta segurança e conectividade estreita são importantes. Para outros aplicativos, alguma conectividade mais flexível é aceitável para maior escalabilidade. Em muitos casos, pode ser melhor começar com alguns dos métodos mais brandos atuais e fazer a transição gradual para conexões mais estreitas ao longo da próxima década, à medida que a tecnologia melhora.