Diferentes tipos de camada 2s

Agradecimentos especiais a Karl Floersch pelo feedback e revisão

O ecossistema Ethereum camada 2 tem se expandido rapidamente no último ano. O ecossistema de rollup EVM, tradicionalmente apresentando Arbitrum, Optimism e Scroll, e mais recentemente Kakarot e Taiko, tem progredido rapidamente, fazendo grandes avanços na melhoria de sua segurança; a página L2beat faz um bom trabalho ao resumir o estado de cada projeto. Além disso, vimos equipes construindo sidechains também começando a construir rollups (Polygon), projetos de camada 1 buscando se tornar validiums (Celo) e esforços totalmente novos (Linea, Zeth…). Finalmente, existe o ecossistema não apenas EVM: “quase EVMs” como Zksync, extensões como Arbitrum Stylus e esforços mais amplos como o ecossistema Starknet, Fuel e outros.

Uma das consequências inevitáveis disto é que estamos a assistir a uma tendência de os projetos da camada 2 se tornarem mais heterogéneos. Espero que esta tendência continue, por algumas razões principais:

• Alguns projetos que atualmente são camadas 1 independentes estão buscando se aproximar do ecossistema Ethereum e possivelmente se tornarem camadas 2. Esses projetos provavelmente necessitarão de uma transição passo a passo. Fazer a transição de uma só vez agora causaria uma diminuição na usabilidade, já que a tecnologia ainda não está pronta para colocar tudo em um rollup. Fazer a transição de uma só vez mais tarde corre o risco de sacrificar o impulso e ser demasiado tarde para ser significativo.
• Alguns projetos centralizados querem dar aos seus usuários mais garantias de segurança e estão explorando rotas baseadas em blockchain para fazer isso. Em muitos casos, estes são os projetos que teriam explorado “cadeias de consórcios autorizados” numa época anterior. Realisticamente, eles provavelmente só precisam de um nível de descentralização de “intermediário”. Além disso, seu nível de rendimento muitas vezes muito alto os torna inadequados até mesmo para rollups, pelo menos no curto prazo.
• As aplicações não financeiras, como jogos ou redes sociais, pretendem ser descentralizadas, mas necessitam apenas de um nível intermédio de segurança. No caso da mídia social, isso envolve realisticamente tratar diferentes partes do aplicativo de maneira diferente: atividades raras e de alto valor, como registro de nome de usuário e recuperação de conta, devem ser feitas em um rollup, mas atividades frequentes e de baixo valor, como postagens e votos, precisam de menos segurança. . Se uma falha na cadeia fizer com que sua postagem desapareça, esse é um custo aceitável. Se uma falha na cadeia fizer com que você perca sua conta, isso será um problema muito maior.

Um grande tema é que, embora os aplicativos e usuários que estão na camada 1 do Ethereum hoje estejam bem pagando taxas de rollup menores, mas ainda visíveis no curto prazo, os usuários do mundo não-blockchain não o farão: é mais fácil justificar o pagamento de US$ 0,10 se você estavam pagando $ 1 antes do que se você estivesse pagando $ 0 antes. Isso se aplica tanto aos aplicativos centralizados hoje quanto às camadas 1 menores, que normalmente cobram taxas muito baixas enquanto sua base de usuários permanece pequena.

Uma questão natural que surge é: qual destas compensações complicadas entre rollups, validiums e outros sistemas faz sentido para uma determinada aplicação?

Rollups vs validiums vs sistemas desconectados

A primeira dimensão de segurança versus escala que exploraremos pode ser descrita da seguinte forma: se você tem um ativo que é emitido em L1, depois depositado em L2 e depois transferido para você, que nível de garantia você tem de que será capaz de levar o ativo de volta ao L1?

Há também uma questão paralela: qual é a escolha tecnológica que resulta nesse nível de garantia e quais são as vantagens dessa escolha tecnológica?

Podemos descrever isso simplesmente usando um gráfico:

https://s3.ap-northeast-1.amazonaws.com/gimg.gateimg.com/learn/b05ca283dcc74f262ac7a71f340dc85fb3a13b11.png

Vale ressaltar que este é um esquema simplificado e existem muitas opções intermediárias. Por exemplo:

• Entre o rollup e o validium: um validium onde qualquer pessoa poderia fazer um pagamento em cadeia para cobrir o custo das taxas de transação, momento em que o operador seria forçado a fornecer alguns dados na cadeia ou então perderia um depósito.
• Entre plasma e validium: um sistema Plasma oferece garantias de segurança semelhantes a rollup com disponibilidade de dados fora da cadeia, mas suporta apenas um número limitado de aplicações. Um sistema poderia oferecer um EVM completo e oferecer garantias de nível Plasma para usuários que não usam esses aplicativos mais complicados, e garantias de nível válido para usuários que o fazem.

Essas opções intermediárias podem ser vistas como estando em um espectro entre um rollup e um validium. Mas o que motiva as aplicações a escolherem um ponto específico desse espectro, e não algum ponto mais à esquerda ou mais à direita? Aqui, existem dois fatores principais:

1. O custo da disponibilidade de dados nativos do Ethereum, que diminuirá com o tempo à medida que a tecnologia melhorar. 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 onchain. Nos próximos anos, espera-se que isso aumente gradualmente à medida que <a href="https://hackmd.io/@vbuterin/sharding_proposal"> danksharding completo for implementado, eventualmente visando cerca de 1,3 MB/s de disponibilidade de dados . Ao mesmo tempo, as melhorias na compressão de dados permitir-nos-ão fazer mais com a mesma quantidade de dados.
2. As próprias necessidades do aplicativo: quanto os usuários sofreriam com taxas altas versus se algo desse errado no aplicativo? As aplicações financeiras perderiam mais com falhas de aplicação; jogos e mídias sociais envolvem muita atividade por usuário e atividades de valor relativamente baixo, portanto, uma compensação de segurança diferente faz sentido para eles.

Aproximadamente, essa compensação é mais ou menos assim:

Outro tipo de garantia parcial que merece destaque são as pré-confirmações. Pré-confirmações são mensagens assinadas por algum conjunto de participantes em um rollup ou validium que diz “atestamos que essas transações estão incluídas neste pedido, e a raiz pós-estado é esta”. Estes participantes podem muito bem assinar uma pré-confirmação que não corresponde a alguma realidade posterior, mas se o fizerem, um depósito será queimado. Isto é útil para aplicações de baixo valor, como pagamentos de consumidores, enquanto aplicações de maior valor, como transferências financeiras multimilionárias, provavelmente aguardarão uma confirmação “regular” apoiada pela segurança total do sistema.

As pré-confirmações podem ser vistas como outro exemplo de sistema híbrido, semelhante ao “híbrido plasma/valium” mencionado acima, mas desta vez hibridizando entre um rollup (ou validium) que tem segurança total, mas alta latência, e um sistema com um nível de segurança muito mais baixo e com baixa latência. Os aplicativos que precisam de menor latência obtêm menor segurança, mas podem viver no mesmo ecossistema que os aplicativos que aceitam maior latência em troca de segurança máxima.

Lendo Ethereum sem confiança

Outra forma de conexão menos pensada, mas ainda muito importante, tem a ver com a capacidade do sistema de ler o blockchain Ethereum. Particularmente, isso inclui a capacidade de reverter se o Ethereum reverter. Para ver por que isso é valioso, considere a seguinte situação:

Suponha que, conforme mostrado no diagrama, a cadeia Ethereum seja revertida. Este pode ser um soluço temporário dentro de uma época, enquanto a cadeia não foi finalizada, ou pode ser um período de vazamento de inatividade em que a cadeia não está sendo finalizada por um longo período porque muitos validadores estão offline.

O pior cenário que pode surgir 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 no Ethereum deposita 100 ETH na cadeia superior. Então, Ethereum reverte. No entanto, a cadeia superior não reverte. Como resultado, os blocos futuros da cadeia superior seguem corretamente os novos blocos da cadeia Ethereum recém-correta, mas as consequências do elo mais antigo, agora errôneo (ou seja, o depósito de 100 ETH) ainda fazem parte da cadeia superior. Essa exploração poderia permitir a impressão de dinheiro, transformando o ETH em ponte na cadeia superior em uma reserva fracionária.

Existem duas maneiras de resolver este problema:

1. A cadeia superior só poderia ler blocos finalizados de Ethereum, portanto nunca precisaria reverter.
2. A cadeia superior pode reverter se o Ethereum reverter. Ambos evitam esse problema. O primeiro é mais fácil de implementar, mas pode causar perda de funcionalidade por um longo período se o Ethereum entrar em um período de vazamento de inatividade. Este último é mais difícil de implementar, mas garante sempre a melhor funcionalidade possível.

Observe que (1) tem um caso extremo. Se um ataque de 51% ao Ethereum criar dois novos blocos incompatíveis que pareçam finalizados ao mesmo tempo, então a cadeia superior pode muito bem travar no bloco errado (ou seja, aquele que o consenso social do Ethereum eventualmente não favorece), e teria que reverter para mudar para o caminho certo. Indiscutivelmente, não há necessidade de escrever código para lidar com esse caso antecipadamente; isso poderia simplesmente ser resolvido com uma bifurcação forte na cadeia superior.

A capacidade de uma rede de ler Ethereum sem confiança é valiosa por dois motivos:

1. Reduz os problemas de segurança envolvidos na ligação de tokens emitidos no Ethereum (ou outros L2s) para essa cadeia
2. Ele permite carteiras de abstração de contas que usam a arquitetura de armazenamento de chaves compartilhadas para manter ativos nessa cadeia com segurança.
3. é importante, embora esta necessidade já seja amplamente reconhecida. (2) também é importante porque significa que você pode ter uma carteira que permite trocas fáceis de chaves e que mantém ativos em um grande número de cadeias diferentes.

Ter uma ponte faz de você um validium?

Suponha que a cadeia superior comece como uma cadeia separada e então alguém coloque no Ethereum um contrato-ponte. Um contrato-ponte é simplesmente um contrato que aceita cabeçalhos de bloco da cadeia superior, verifica se qualquer cabeçalho submetido a ele vem com um certificado válido mostrando que foi aceito pelo consenso da cadeia superior e adiciona esse cabeçalho a uma lista. Os aplicativos podem ser desenvolvidos com base nisso para implementar funcionalidades como depósito e retirada de tokens. Uma vez estabelecida essa ponte, será que isso proporciona alguma das garantias de segurança patrimonial que mencionámos anteriormente?

Até agora, ainda não! Por dois motivos:

1. Estamos validando se os blocos foram assinados, mas não se as transições de estado estão corretas. Portanto, se você tiver um ativo emitido no Ethereum depositado na cadeia superior e os validadores da cadeia superior se tornarem desonestos, eles poderão assinar uma transição de estado inválida que rouba esses ativos.
2. A rede superior ainda não tem como ler Ethereum. Conseqüentemente, você não pode nem mesmo depositar ativos nativos do Ethereum na cadeia superior sem depender de alguma outra ponte de terceiros (possivelmente insegura).

Agora, vamos fazer da ponte uma ponte de validação: ela verifica não apenas o consenso, mas também um ZK-SNARK provando que o estado de qualquer novo bloco foi calculado corretamente.

Feito isso, os validadores da rede principal não poderão mais roubar seus fundos. Eles podem publicar um bloco com dados indisponíveis, impedindo que todos retirem, mas não podem roubar (exceto tentando extrair um resgate para os usuários em troca da revelação dos dados que lhes permitem retirar). Este é o mesmo modelo de segurança de um validium.

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:

1. Coloque um contrato-ponte validando os blocos Ethereum finalizados dentro da cadeia superior.
2. Faça com que cada bloco na cadeia superior contenha um hash de um bloco Ethereum recente e tenha uma regra de escolha de fork que imponha as ligações de hash. Ou seja, um bloco de cadeia superior vinculado a um bloco Ethereum que não está na cadeia canônica é ele próprio não canônico, e se um bloco de cadeia superior vinculado a um bloco Ethereum que era inicialmente canônico, mas depois se torna não canônico, o bloco da cadeia superior também deve se tornar não canônico.

Os links roxos podem ser links hash ou um contrato de ponte que verifica o consenso do Ethereum.

Isso é suficiente? Acontece que ainda não, por causa de alguns pequenos casos extremos:

1. O que acontecerá se o Ethereum for atacado em 51%?
2. Como você lida com as atualizações do hard fork Ethereum?
3. Como você lida com atualizações de hard fork de sua cadeia?

Um ataque de 51% ao Ethereum teria consequências semelhantes a um ataque de 51% à cadeia superior, mas ao contrário. Um hard fork do Ethereum corre o risco de tornar a ponte do Ethereum dentro da cadeia superior inválida. Um compromisso social de reverter se o Ethereum reverter um bloco finalizado, e de fazer um hard fork se o Ethereum fizer um hard fork, é a maneira mais limpa de resolver isso. Tal compromisso pode muito bem nunca precisar ser realmente executado: você poderia ter um dispositivo de governança na cadeia superior ativado se ele vir a prova de um possível ataque ou hard fork, e apenas fazer um hard fork na cadeia superior se o dispositivo de governança falhar.

A única resposta viável para (3) é, infelizmente, ter algum tipo de dispositivo de governança no Ethereum que possa tornar o contrato-ponte no Ethereum ciente das atualizações hard-fork da cadeia superior.

Resumo: pontes de validação bidirecionais são quase suficientes para transformar uma cadeia em validium. O principal ingrediente restante é um compromisso social de que se algo excepcional acontecer no Ethereum que faça com que a ponte não funcione mais, a outra cadeia fará um hard fork em resposta.

Conclusões

Existem duas dimensões principais para a “conectividade com Ethereum”:

1. Segurança de retirada para Ethereum
2. Segurança de leitura do Ethereum

Ambos são importantes e têm considerações diferentes. Existe um espectro em ambos os casos:

Observe que ambas as dimensões têm duas maneiras distintas de medi-las (então realmente existem quatro dimensões?): a segurança da retirada pode ser medida por (i) nível de segurança e (ii) que porcentagem de usuários ou casos de uso se beneficiam da segurança mais alta nível, e a segurança da leitura pode ser medida por (i) quão rapidamente a cadeia pode ler os blocos do Ethereum, particularmente blocos finalizados versus quaisquer blocos, e (ii) a força do compromisso social da cadeia para lidar com casos extremos, como ataques de 51% e garfos duros.

Há valor em projetos em muitas regiões deste espaço de design. Para algumas aplicações, alta segurança e forte conectividade são importantes. Para outros, algo mais flexível é aceitável em troca de maior escalabilidade. Em muitos casos, começar com algo mais frouxo hoje e passar para um acoplamento mais estreito ao longo da próxima década, à medida que a tecnologia melhora, pode muito bem ser o ideal.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [Vitalik Buterin]. Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.