Agradecimentos especiais a Karl Floersch pelo feedback e revisão

O ecossistema da camada 2 do Ethereum tem vindo a expandir-se rapidamente no último ano. O ecossistema de rollup EVM, tradicionalmente com Arbitrum, Optimism and Scroll, e mais recentemente Kakarot e Taiko, tem progredido rapidamente, fazendo grandes progressos na melhoria da sua segurança; a página L2beat faz um bom trabalho ao resumir o estado de cada projeto. Além disso, vimos equipas a construir cadeias laterais também a começar a construir rollups (Polygon), projetos de camada 1 que procuram passar a ser validiums (Celo), e esforços totalmente novos (Linea, Zeth...). Finalmente, existe o ecossistema não-just-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 disso é que estamos a ver uma tendência de projetos de camada 2 a tornarem-se mais heterogéneos. Espero que esta tendência continue, por algumas razões principais:

• Alguns projetos que atualmente são independentes da camada 1s procuram aproximar-se do ecossistema Ethereum e possivelmente tornar-se a camada 2s. Estes projetos provavelmente vão querer uma transição passo a passo. A transição de uma só vez agora causaria uma diminuição na usabilidade, uma vez que a tecnologia ainda não está pronta para colocar tudo num conjunto. A transição de uma só vez mais tarde corre o risco de sacrificar o ímpeto e ser tarde demais para ser significativo.
• Alguns projetos centralizados querem dar aos seus utilizadores mais garantias de segurança e estão a explorar rotas baseadas em blockchain para o fazer. Em muitos casos, estes são os projetos que teriam explorado “cadeias de consórcios permissionadas” numa era anterior. Realisticamente, provavelmente só precisam de um nível de descentralização “Halfway-house”. Além disso, o seu nível de rendimento muitas vezes muito elevado torna-os inadequados mesmo para rollups, pelo menos a curto prazo.
• As aplicações não financeiras, como jogos ou redes sociais, querem ser descentralizadas mas precisam apenas de um nível de segurança intermédio. No caso das redes sociais, isto envolve, realisticamente, tratar diferentes partes da aplicação de forma diferente: atividades raras e de alto valor como registo de nome de utilizador e recuperação de conta devem ser feitas num conjunto, mas atividades frequentes e de baixo valor como postagens e votos precisam de menos segurança. Se uma falha na cadeia faz com que a sua postagem desapareça, isso é um custo aceitável. Se uma falha na cadeia faz com que perca a sua conta, isso é 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 $0,10 se estava a pagar $1 antes do que se estivesse a pagar $0 antes. Isto aplica-se tanto às aplicações que estão centralizadas hoje, como às camadas 1s mais pequenas, que normalmente têm taxas muito baixas enquanto a sua base de utilizadores permanece pequena.

Uma questão natural que surge é: qual dessas 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 vs escala que exploraremos pode ser descrita da seguinte forma: se tem um ativo emitido em L1, depois depositado no L2 e depois transferido para si, que nível de garantia tem de poder levar o ativo de volta para o L1?

Há também uma questão paralela: qual é a escolha da tecnologia que está a resultar nesse nível de garantia e quais são as compensações dessa escolha de tecnologia?

Podemos descrever isto simplesmente usando um gráfico:

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

Vale a pena mencionar que este é um esquema simplificado e há muitas opções intermédias. Por exemplo:

• Entre rollup e valídio: um valídio onde qualquer pessoa poderia fazer um pagamento em cadeia para cobrir o custo das taxas de transação, altura 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 tipo 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 aos utilizadores que não utilizam essas aplicações mais complicadas, e garantias de nível de validio aos utilizadores que o fazem.

Estas opções intermédias podem ser vistas como estando num espectro entre um rollup e um valídio. Mas o que motiva as aplicações a escolherem um ponto específico nesse 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 ~32 Kb/seg de disponibilidade de dados na cadeia. Nos próximos anos, espera-se que isso aumente em fases à medida que < a href= " https://hackmd.io/@vbuterin/sharding_proposta " > full danksharding 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 da aplicação: quanto os utilizadores sofreriam com taxas elevadas, em comparação com algo na aplicação a correr mal? As aplicações financeiras perderiam mais com falhas de aplicação; os jogos e as redes sociais envolvem muita atividade por utilizador e uma atividade de valor relativamente baixo, pelo que uma compensação de segurança diferente faz sentido para eles.

Aproximadamente, este tradeoff parece algo como isto:

Outro tipo de garantia parcial que vale a pena mencionar são as pré-confirmações. As pré-confirmações são mensagens assinadas por algum conjunto de participantes num pacote rollup ou valídio que dizem “atestamos que estas transações estão incluídas nesta ordem, 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 é queimado. Isto é útil para aplicações de baixo valor, como pagamentos ao consumidor, enquanto aplicações de valor mais elevado, como transferências financeiras multimilionárias, provavelmente esperarão por 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/ validium” mencionado acima, mas desta vez hibridização entre um rollup (ou valídio) que tem segurança total mas alta latência, e um sistema com um nível de segurança muito mais baixo que tem baixa latência. As aplicações que necessitam de menor latência obtêm menor segurança, mas podem viver no mesmo ecossistema que as aplicações que estão bem com maior latência em troca de segurança máxima.

Ler Ethereum sem confiança

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

Suponha que, conforme mostrado no diagrama, a cadeia Ethereum reverta. Isso 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 fuga de inatividade em que a cadeia não está a ser finalizada por um período prolongado porque muitos validadores estão offline.

O pior cenário que pode surgir disso é o seguinte. Suponha que o primeiro bloco da cadeia superior lê alguns dados do bloco mais à esquerda da cadeia Ethereum. Por exemplo, alguém no Ethereum deposita 100 ETH na cadeia superior. Então, o Ethereum reverte. No entanto, a cadeia superior não reverte. Como resultado, os futuros blocos da cadeia superior seguem corretamente os novos blocos da cadeia Ethereum recentemente correta, mas as consequências do agora erróneo elo mais antigo (ou seja, o depósito de 100 ETH) ainda fazem parte da cadeia superior. Este exploit poderia permitir imprimir dinheiro, transformar a ETH ligada na cadeia superior numa reserva fracionária.

Existem duas maneiras de resolver este problema:

1. A cadeia superior só podia ler blocos finalizados de Ethereum, por isso nunca precisaria de reverter.
2. A cadeia superior pode reverter se o Ethereum reverter. Ambos evitam este problema. O primeiro é mais fácil de implementar, mas pode causar uma perda de funcionalidade por um período prolongado se o Ethereum entrar num período de fuga de inatividade. Este último é mais difícil de implementar, mas garante a melhor funcionalidade possível em todos os momentos.

Note que (1) tem um caso extremo. Se um ataque de 51% ao Ethereum criar dois novos blocos incompatíveis que parecem finalizados ao mesmo tempo, então a cadeia superior pode muito bem fixar-se no errado (ou seja. aquele que o consenso social do Ethereum não favorece eventualmente), e teria de reverter para mudar para o correto. Indiscutivelmente, não há necessidade de escrever código para lidar com este caso antes do tempo; poderia simplesmente ser tratado através de uma bifurcação rígida da cadeia superior.

A capacidade de uma cadeia ler Ethereum sem confiança é valiosa por duas razões:

1. Reduz os problemas de segurança envolvidos na ligação de tokens emitidos no Ethereum (ou outros L2s) a essa cadeia
2. Permite que carteiras de abstração de contas que usam a arquitetura de armazenamento de chaves partilhado para manter ativos nessa cadeia de forma segura.
3. é importante, embora indiscutivelmente esta necessidade já seja amplamente reconhecida. (2) também é importante, porque significa que pode ter uma carteira que permite mudanças fáceis de chave e que detém ativos num grande número de cadeias diferentes.

Ter uma ponte faz de si um valídio?

Suponha que a cadeia superior comece como uma cadeia separada e depois alguém coloque no Ethereum um contrato de ponte. Um contrato de ponte é simplesmente um contrato que aceita cabeçalhos de bloco da cadeia superior, verifica se qualquer cabeçalho enviado 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. As aplicações podem ser construídas em cima disso para implementar funcionalidades como depositar e retirar tokens. Uma vez que essa ponte esteja em vigor, isso fornece alguma das garantias de segurança dos ativos que mencionamos anteriormente?

Até agora, ainda não! Por duas razões:

1. Estamos a validar que os blocos foram assinados, mas não que as transições de estado estão corretas. Portanto, se tiver um ativo emitido no Ethereum depositado na cadeia superior e os validadores da cadeia superior ficarem desonestos, eles podem assinar uma transição de estado inválida que rouba esses ativos.
2. A cadeia de topo ainda não tem como ler Ethereum. Por isso, não pode sequer depositar ativos nativos do Ethereum na cadeia superior sem depender de outra ponte de terceiros (possivelmente insegura).

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

Feito isso, os validadores da cadeia superior não podem mais roubar os seus fundos. Podem publicar um bloco com dados indisponíveis, impedindo que todos se retirem, mas não podem roubar (excepto tentando extrair um resgate para os utilizadores em troca de revelarem os dados que lhes permitem retirar). Este é o mesmo modelo de segurança que um valídio.

No entanto, ainda não resolvemos o segundo problema: a cadeia superior não consegue ler Ethereum.

Para fazer isso, precisamos de fazer uma de duas coisas:

1. Coloque um contrato de ponte validando os blocos Ethereum finalizados dentro da cadeia superior.
2. Cada bloco da cadeia superior contém um hash de um bloco Ethereum recente e tem uma regra de escolha de fork que impõe os links de hash. Ou seja, um bloco da cadeia superior que se liga a um bloco Ethereum que não está na cadeia canónica é em si não canónico, e se um bloco da cadeia superior se liga 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 tornar-se não-canónico.

Os links roxos podem ser hash links 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 acontece se o Ethereum for atacado com 51%?
2. Como lida com upgrades de hard fork do Ethereum?
3. Como lida com upgrades de hard fork da sua cadeia?

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

A única resposta viável para (3) é, infelizmente, ter alguma forma de dispositivo de governança no Ethereum que possa fazer com que o contrato de ponte no Ethereum esteja ciente de upgrades de hard-fork da cadeia superior.

Resumo: pontes de validação bidirecional são quase suficientes para fazer de uma corrente um valídio. 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 irá fork em resposta.

Conclusões

Existem duas dimensões-chave para a “conexão com o Ethereum”:

1. Segurança de retirada para Ethereum
2. Segurança de ler Ethereum

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

Observe que ambas as dimensões têm duas maneiras distintas de medi-las (então, realmente, há quatro dimensões?) : a segurança da retirada pode ser medida pelo (i) nível de segurança e (ii) qual a percentagem de utilizadores ou casos de utilização beneficiam do mais alto nível de segurança, e a segurança da leitura pode ser medida pela (i) a rapidez com que a cadeia pode ler os blocos do Ethereum, particularmente os blocos finalizados versus quaisquer blocos, e (ii) a força do compromisso social da cadeia para lidar com casos extremos como 51% de ataques e hard forks.

Há valor em projetos em muitas regiões deste espaço de design. Para algumas aplicações, a alta segurança e a conexão estreita são importantes. Para outros, algo mais solto é aceitável em troca de uma maior escalabilidade. Em muitos casos, começar com algo mais solto hoje, e passar para um acoplamento mais apertado na 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 de autor pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.