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:
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?
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:
Vale ressaltar que este é um esquema simplificado e existem muitas opções intermediárias. Por exemplo:
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:
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.
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:
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:
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:
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:
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:
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.
Existem duas dimensões principais para a “conectividade com 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.
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:
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?
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:
Vale ressaltar que este é um esquema simplificado e existem muitas opções intermediárias. Por exemplo:
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:
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.
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:
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:
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:
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:
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:
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.
Existem duas dimensões principais para a “conectividade com 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.