Vitalik: Analisando as diferentes categorias de L2

Os projetos L2 tenderão cada vez mais à heterogeneidade.

Título original: 《Different types of layer 2s》

Autor: Vitalik Buterin

Tradução: BlockBeats

O ecossistema expandiu-se rapidamente no último ano. Tradicionalmente representado por StarkNet, Arbitrum, Optimism e Scroll, o ecossistema ZK-EVM rollup tem avançado rapidamente, aumentando continuamente a sua segurança. A página L2beat resume muito bem o estado de cada projeto.

Além disso, temos visto algumas equipas a construir sidechains enquanto também começam a desenvolver soluções de rollup (como Polygon), alguns projetos L1 a tentar evoluir para validação de validade (como Celo), e ainda novas tentativas (como Linea, Zeth…).

Um dos resultados inevitáveis é que vemos os projetos L2 tenderem a ser cada vez mais heterogéneos (heterogeneous). Nota do tradutor: No contexto cripto, “heterogeneidade” refere-se à coexistência ou mistura de diferentes tipos ou naturezas de elementos. Este termo é normalmente usado para descrever blockchains, protocolos, tecnologias ou ativos distintos, que possuem diferentes características, regras ou propriedades. Espero que esta tendência continue, pelas seguintes razões:

Atualmente, alguns projetos L1 independentes procuram uma ligação mais estreita ao ecossistema Ethereum, podendo eventualmente transformar-se em projetos L2. Estes projetos podem querer adotar uma transição faseada. Uma transição total imediata reduziria a usabilidade, pois a tecnologia ainda não está pronta para colocar tudo em soluções rollup. Por outro lado, uma transição total tardia pode sacrificar o momentum e não ser suficientemente relevante.

Alguns projetos centralizados querem oferecer mais garantias de segurança aos seus utilizadores e estão a explorar abordagens baseadas em blockchain. Em muitos casos, estes projetos poderiam anteriormente ter considerado “blockchains de consórcio permissionados”. Na prática, podem apenas precisar de atingir um nível de “semi-centralização”. Além disso, normalmente apresentam uma taxa de throughput muito elevada, pelo menos a curto prazo, não sendo adequados para soluções rollup.

Aplicações não financeiras, como jogos ou redes sociais, pretendem descentralização, mas apenas necessitam de um certo grau de segurança.

No caso das redes sociais, há diferentes partes da aplicação a serem tratadas de formas distintas: atividades raras e de alto valor, como registo de nomes de utilizador e recuperação de contas, devem ser realizadas em soluções rollup; mas atividades frequentes e de baixo valor, como posts e votos, requerem menos garantias de segurança — se uma falha na blockchain fizer desaparecer o seu post, é um custo aceitável; mas se perder a sua conta, o problema é muito mais grave.

Um tema importante é que, embora atualmente as aplicações e utilizadores no Ethereum L1 estejam dispostos a pagar taxas de rollup pequenas mas ainda visíveis, os utilizadores vindos do mundo não-blockchain não estão tão dispostos: se antes pagava 1 dólar, pagar 0,10 dólares é mais aceitável, mas se antes pagava 0 dólares, torna-se difícil aceitar.

Isto aplica-se tanto a aplicações que ainda são centralizadas hoje, como a pequenos projetos L1 que normalmente têm taxas extremamente baixas devido à sua base de utilizadores reduzida.

Uma questão natural é: para uma aplicação específica, qual destas complexas compensações entre soluções rollup, validiums (validação de validade) e outros sistemas é a mais razoável?

Rollups vs Validiums vs Sistemas Desconectados

O primeiro eixo de segurança e escalabilidade que vamos explorar pode ser descrito assim: se possui um ativo emitido no L1, depois o deposita num L2 e o transfere para si, até que ponto pode garantir que conseguirá recuperar o ativo de volta para o L1?

Há ainda uma questão relacionada: que escolhas técnicas levam a esse grau de garantia, e quais são as compensações dessas escolhas?

Podemos descrever esta questão com um gráfico simples:

Vale a pena referir que este é um esquema simplificado, existindo muitas opções intermédias. Por exemplo:

Entre rollup e validium: num validium, qualquer pessoa pode efetuar um pagamento on-chain para cobrir taxas de transação, obrigando o operador a fornecer alguns dados on-chain, sob pena de perder o depósito.

Entre plasma e validium: um sistema Plasma oferece garantias de segurança semelhantes a rollup, com disponibilidade de dados off-chain, mas apenas suporta um número limitado de aplicações. Um sistema pode oferecer EVM completo e, para utilizadores que não usam essas aplicações mais complexas, fornecer garantias ao nível Plasma, e para quem as usa, garantias ao nível validium.

Estas opções intermédias podem ser vistas como um espectro entre rollup e validium. Mas o que leva uma aplicação a escolher um ponto específico desse espectro, em vez de um mais à esquerda ou à direita? Aqui, há dois fatores principais:

1. O custo da disponibilidade de dados nativa do Ethereum, que diminuirá ao longo do tempo com o avanço tecnológico. O próximo hard fork do Ethereum, Dencun, introduz o EIP-4844 (também conhecido como “proto-danksharding”), que oferece cerca de 32 kB/segundo de disponibilidade de dados on-chain.

Prevê-se que, nos próximos anos, com a implementação completa do danksharding, esta disponibilidade de dados aumente gradualmente, com o objetivo final de cerca de 1,3 MB/segundo. Ao mesmo tempo, melhorias na compressão de dados permitirão fazer mais com a mesma quantidade de dados.

2. As necessidades da própria aplicação: quão grave é para os utilizadores perderem devido a taxas elevadas, em comparação com problemas na aplicação? Aplicações financeiras perdem mais com falhas; jogos e redes sociais envolvem grandes volumes de atividade de baixo valor, pelo que diferentes compensações de segurança fazem sentido para elas.

Esta compensação pode ser representada aproximadamente assim:

Outro tipo digno de nota são as pré-confirmações (pre-confirmations). Pré-confirmações são mensagens assinadas por um grupo de participantes num rollup ou validium, indicando “atestamos que estas transações estão incluídas nesta ordem e que o post-state root é este”. Estes participantes podem assinar uma pré-confirmação incorreta, mas se o fizerem, o seu depósito será destruído.

Isto é muito útil para aplicações de baixo valor (como pagamentos de consumo), enquanto aplicações de alto valor (como transferências financeiras de milhões de dólares) podem esperar pela confirmação “regular” suportada pela segurança total do sistema.

As pré-confirmações podem ser vistas como outro exemplo de sistema híbrido, semelhante ao “plasma/validium híbrido” mencionado acima, mas desta vez misturando rollups (ou validiums) com segurança total mas alta latência, com sistemas de menor segurança mas baixa latência. Aplicações que necessitam de baixa latência obtêm menor segurança, mas podem coexistir no mesmo ecossistema com aplicações que preferem maior segurança e aceitam maior latência.

Leitura sem confiança do Ethereum

Outra forma de ligação, menos considerada mas ainda muito importante, está relacionada com a capacidade de um sistema ler a blockchain Ethereum. Especificamente, isto inclui a capacidade de um sistema reverter se o Ethereum sofrer um rollback. Para perceber o valor disto, considere o seguinte cenário:

Suponha, como ilustrado, que a blockchain Ethereum sofre um rollback. Isto pode ser uma interrupção temporária dentro de uma época, antes da finalização da blockchain; ou pode ser um período de inatividade prolongada devido a demasiados validadores offline, impedindo a finalização.

O pior cenário possível é o seguinte: suponha que o primeiro bloco da cadeia superior (top chain) lê alguns dados do bloco mais à esquerda da cadeia Ethereum. Por exemplo, alguém deposita 100 ETH no top chain via Ethereum. Depois, o Ethereum sofre um rollback, mas o top chain não reverte. Como resultado, os blocos futuros do top chain seguem corretamente os novos blocos Ethereum, mas a transação errada (os 100 ETH depositados) permanece no top chain. Esta vulnerabilidade pode levar à inflação da moeda, tornando o ETH bridgeado no top chain parcialmente colateralizado.

Existem duas formas de resolver este problema:

1. O top chain só pode ler blocos Ethereum já finalizados, nunca necessitando de rollback;

2. Se o Ethereum sofrer rollback, o top chain também pode reverter. Ambas previnem este problema. A primeira é mais fácil de implementar, mas se o Ethereum entrar em período de inatividade, pode perder funcionalidade por muito tempo. A segunda é mais difícil, mas garante sempre a melhor funcionalidade.

Note que a primeira abordagem tem uma exceção: se o Ethereum sofrer um ataque de 51%, levando a dois blocos incompatíveis aparentemente finalizados, o top chain pode escolher o bloco errado (não apoiado pelo consenso social do Ethereum) e terá de reverter para o correto. Pode-se argumentar que não é necessário programar para este caso de antemão; pode ser resolvido com um hard fork do top chain.

A capacidade de blockchains lerem o Ethereum sem confiança é importante por duas razões:

Primeiro, reduz os riscos de segurança ao fazer bridge de tokens emitidos no Ethereum (ou outras soluções layer 2) para essa cadeia;

Segundo, permite que carteiras de abstração de contas com armazenamento de chaves partilhado possam manter ativos com segurança nessa cadeia.

Apesar de controversa, a importância da primeira abordagem já é amplamente reconhecida. Da mesma forma, a segunda também é importante, pois permite ter uma carteira que muda facilmente de chave e detém ativos em várias cadeias diferentes.

Ter um bridge pode tornar-se um validium?

Suponha que o top chain é lançado inicialmente como uma cadeia independente, e alguém implementa um contrato bridge no Ethereum. O contrato bridge apenas aceita block headers do top chain, verificando se qualquer header submetido tem um certificado válido, provando que foi aceite pelo consenso do top chain, e adiciona esse header à lista.

Aplicações podem construir funcionalidades como depósitos e levantamentos de tokens com base nisto. Uma vez estabelecida esta bridge, ela oferece alguma das garantias de segurança de ativos mencionadas anteriormente?

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

1. Estamos a verificar assinaturas dos blocos, mas não se a transição de estado é correta. Assim, se depositar um ativo emitido no Ethereum no top chain e os validadores do top chain forem desonestos, podem assinar uma transição de estado inválida e roubar os ativos;

2. O top chain ainda não consegue ler o Ethereum. Por isso, não pode depositar ativos nativos do Ethereum no top chain sem depender de outras bridges (potencialmente inseguras) de terceiros.

Agora, vamos construir o bridge como um bridge de validação: além de verificar o consenso, também verifica se qualquer novo bloco submetido foi corretamente calculado com uma prova ZK-SNARK.

Depois deste passo, os validadores do top chain já não podem roubar os seus fundos. Podem publicar um bloco com dados indisponíveis, impedindo todos de levantar fundos, mas não podem roubá-los (a menos que tentem extorquir os utilizadores para revelar os dados necessários para o levantamento). Isto corresponde ao mesmo modelo de segurança do validium.

No entanto, ainda não resolvemos o segundo problema: o top chain não consegue ler dados do Ethereum. Para isso, precisamos de uma das duas abordagens:

1. Colocar um contrato bridge no top chain que verifica blocos Ethereum já finalizados;

2. Incluir em cada bloco do top chain o hash de um bloco Ethereum recente, e adotar uma regra de seleção de fork que force a ligação de hashes. Ou seja, blocos do top chain ligados a blocos Ethereum fora da cadeia principal também são considerados fora da cadeia principal. Se o bloco Ethereum ligado inicialmente estava na cadeia principal mas depois deixa de estar, o bloco do top chain também deve deixar de estar.

Estas ligações roxas podem ser links de hash ou contratos bridge que verificam o consenso do Ethereum

Será isto suficiente? Na verdade, ainda não, pois há algumas situações de exceção:

1. O que acontece se o Ethereum sofrer um ataque de 51%?

2. Como lidar com upgrades de hard fork do Ethereum?

3. Como lidar com upgrades de hard fork da sua própria cadeia?

Um ataque de 51% ao Ethereum terá consequências semelhantes a um ataque de 51% ao top chain, mas ao contrário. Um hard fork do Ethereum pode invalidar bridges do Ethereum dentro do top chain. Um compromisso social — ou seja, se o Ethereum reverter um bloco finalizado, também se reverte; se o Ethereum fizer hard fork, também se faz hard fork — é a solução mais limpa.

Na prática, este compromisso pode nunca precisar de ser executado: se a governação do top chain detetar sinais de ataque ou hard fork iminente, pode ativar a governação, e só recorrer ao hard fork do top chain se a governação falhar.

Para a terceira questão, a única resposta viável é estabelecer algum tipo de governação no Ethereum, permitindo que o contrato bridge no Ethereum reconheça upgrades de hard fork do top chain.

Resumo: bridges de validação bidirecional são quase suficientes para tornar uma blockchain num validium. O principal elemento em falta é um compromisso social de que, se o Ethereum tiver uma anomalia que impeça o funcionamento do contrato bridge, a outra blockchain fará um hard fork em resposta.

Conclusão

“Ligar-se ao Ethereum” tem duas dimensões-chave:

1. Segurança de extração para o Ethereum;

2. Segurança de leitura do Ethereum.

Ambas são muito importantes e têm diferentes considerações. Em ambos os casos existe um espectro contínuo:

Note que cada dimensão tem duas formas diferentes de medição (na verdade, são quatro dimensões): a segurança de extração pode ser medida por (i) nível de segurança, e (ii) quantos utilizadores ou casos de uso beneficiam do nível máximo de segurança;

Já a segurança de leitura pode ser medida por (i) quão rapidamente a ligação pode ler blocos do Ethereum, especialmente distinguindo blocos finalizados de quaisquer blocos, e (ii) o grau de compromisso social da ligação ao lidar com situações de exceção como ataques de 51% e hard forks.

Há valor em projetos em muitas áreas deste espaço de design. Para algumas aplicações, segurança elevada e ligação estreita são essenciais. Para outras, condições mais flexíveis podem ser aceitáveis para maior escalabilidade. Em muitos casos, começar hoje com condições mais flexíveis e, à medida que a tecnologia evolui, transitar gradualmente para uma ligação mais estreita ao longo da próxima década pode ser a escolha ideal.