Escalabilidade no Ethereum

Introdução

Ao longo de sua história, tanto o Ethereum quanto outras blockchains receberam uma série de melhorias com o objetivo de avançar em certos aspectos-chave de seu funcionamento. Em geral, essas melhorias se concentram nos três pilares fundamentais dessas tecnologias: segurança, descentralização e escalabilidade.

Embora grandes marcos tenham sido alcançados em relação a esses aspectos, o trabalho ainda não terminou. Mas, para entender quais são os limites atuais dessa tecnologia, é necessário aprofundar-se em seu estado atual e detalhar os componentes envolvidos.

Hoje, vamos nos concentrar na escalabilidade. Trata-se talvez do aspecto mais crítico para a evolução do Ethereum — mas para explicar o porquê, precisamos primeiro definir o que entendemos por escalabilidade no contexto do Ethereum.

O que é Escalabilidade?

De forma geral, escalabilidade significa a capacidade de um sistema processar uma quantidade crescente de trabalho ou tráfego. Para uma blockchain, isso se traduz diretamente na possibilidade de processar um maior número de transações por segundo (TPS), mantendo ao mesmo tempo baixos os custos de transação e os tempos de confirmação.

É claro que isso é muito importante para que a experiência de uso do Ethereum seja boa para os usuários. Atualmente, a rede processa em torno de 15 a 20 transações por segundo, o que podemos facilmente verificar ao inspecionar os blocos em plataformas como etherscan.io (observando o número de transações por bloco e o tempo de cada bloco, que é de 12 segundos).

Existem algumas complicações nesse caminho. Nem todas as transações são iguais — por exemplo, uma simples transferência de $ETH é muito diferente de uma chamada a um contrato em que os parâmetros (que viajam no CALLDATA) podem ocupar uma grande quantidade de bytes. Além disso, todas as informações das transações ficam armazenadas nos blocos da cadeia, e esses blocos têm restrições de tamanho.

Uma alternativa para processar mais transações seria aumentar o tamanho dos blocos. Parece simples, mas isso traz outros problemas. Não podemos esquecer que, para alcançar o consenso, os blocos precisam ser transmitidos entre os nós da rede — e quanto maiores eles forem, mais lentas serão as comunicações. A rede terá mais latência, e todo o processo ficará mais lento. É um equilíbrio delicado.

Como se não bastasse, certos atores complicam ainda mais a situação: as soluções de camada 2 (layer 2), ou rollups. Elas processam milhares de transações por segundo e depois publicam o resultado no Ethereum. Em outras palavras, usam a rede como uma camada de liquidação: ao publicar esses dados periodicamente, deixam um registro imutável no Ethereum. Esses dados costumavam ser publicados em forma de CALLDATA — portanto, mais rollups significava mais dificuldade para a rede escalar.

Esse era o estado da rede antes da atualização Dencun, que chegou à mainnet no início de 2024. A atualização incluiu o EIP-4844, também conhecido como Proto-Danksharding, que marcou o início de um caminho para melhorar a escalabilidade da layer 1.

Disponibilidade de Dados

A questão central é: realmente precisamos armazenar a informação no Ethereum através de CALLDATA, ou existe alguma outra solução? Os rollups publicam as transações com o objetivo de criar um registro não apenas imutável, mas também verificável, de forma que permite a atores como nós e indexadores acessar os dados das transações e entender como a rede está evoluindo.

Os dados armazenados com CALLDATA permanecem indefinidamente na blockchain e geram custos de processamento, já que a EVM os trata como qualquer outro payload. Esse é um custo que os rollups precisam pagar e, em última instância, repassam para os usuários.

Em outras palavras, o que realmente precisamos é garantir a disponibilidade desses dados. E aqui está a pergunta fundamental: é realmente necessário que esses dados fiquem disponíveis para sempre, ou apenas pelo tempo suficiente para sua verificação?

---

Proto-Danksharding

Para resolver isso, o Proto-Danksharding introduz a ideia de blobs: simplesmente dados que permanecem armazenados por um período determinado (4096 epochs, atualmente cerca de 18 dias) e depois são descartados.

Os blobs têm um tamanho máximo de 128 kilobytes e podem ser inspecionados em sites como blobscan.com.

Esse tempo é mais do que suficiente para que quem precise desses dados possa acessá-los. O ponto crucial é que esses blobs não são publicados através de CALLDATA, sendo, portanto, uma alternativa muito mais barata.

Sem dúvida, parece promissor. Mas naturalmente surge a próxima pergunta: se não é no estado da blockchain, onde esses dados ficam armazenados?

Na prática, eles são transmitidos junto com os blocos, e os nós que os recebem simplesmente os guardam na memória. Mas, como não fazem parte do estado da blockchain, é necessário algum mecanismo para verificar sua integridade. Caso contrário, quem consome os dados não teria como confirmar se os blobs não foram corrompidos ou alterados.

A solução é armazenar de forma permanente algum tipo de identificador curto na rede, que permita verificar rapidamente a integridade dos dados. Isso pode ser feito, por exemplo, salvando o hash do blob, que funciona como uma “impressão digital” criptográfica única.

Existem outras formas de alcançar o mesmo efeito, como através de Merkle trees (que é a forma como os nós de execução operam).

No Proto-Danksharding, foi escolhido o uso de um esquema de compromisso polinomial chamado KZG (Kate-Zaverucha-Goldberg), cuja função é exatamente essa: reduzir um blob inteiro a um identificador verificável. Essa decisão também está relacionada à compatibilidade potencial com provas de conhecimento zero (ZK proofs).

Perfeito! Com isso, podemos armazenar dados de forma barata e verificável no Ethereum, permitindo que os rollups operem sem congestionar a rede.

Mas será que o problema está realmente resolvido? Como quase sempre acontece… não é tão simples.

Limitações

Imaginemos que começamos a anexar esses blobs aos blocos. Quantos podemos incluir?

Embora os blobs não façam parte do estado do Ethereum, o problema é que os nós precisam transmiti-los pela rede junto com os blocos. Soa familiar? É exatamente o mesmo problema que mencionamos no início deste artigo: quanto mais blobs, maior a latência da rede. E não apenas pela transmissão em si — lembremos que os blobs precisam ser verificados.

Além disso, pode haver maior demanda de memória (hardware) para os nós que armazenam esses blobs. A título ilustrativo, façamos o exercício de calcular de quanta memória estamos falando: imaginemos que pudéssemos armazenar 100 blobs por bloco. Considerando que os blobs são guardados por 4096 epochs, que correspondem a 131072 slots, e que cada blob tem um tamanho máximo de 128 kilobytes, estaríamos falando de uma capacidade de armazenamento somente para blobs de 1,6 terabytes!

Portanto, novamente, existe um limite de quantos blobs podemos incluir por bloco, de forma que a rede não seja excessivamente afetada (e os slots possam continuar sendo mantidos em 12 segundos). Atualmente, a rede suporta apenas 6 blobs por bloco.

Isso gera uma certa tensão: agora os rollups competem por esse novo “blobspace”, e em períodos de muita atividade, o preço desse recurso pode disparar, o que, obviamente, impacta os rollups. Idealmente, gostaríamos de poder incluir mais blobs por bloco para aliviar essa pressão — mas já vimos que não é possível sem afetar significativamente a rede.

Então, como resolver esse problema?

Danksharding

O Proto-Danksharding foi criado como um passo intermediário entre a versão anterior do Ethereum e a visão conhecida como Danksharding.

A ideia principal é aumentar o número de blobs por bloco, de 6 para 64. Mas, para chegar a isso sem esbarrar nos problemas que mencionamos antes, certas condições precisam ser atendidas, relacionadas a outros marcos na evolução da rede, como:

• Proposer-Builder Separation
• Data Availability Sampling

Em breve, exploraremos mais sobre esses temas, explicando o papel dessas propostas na realização do Danksharding.

E a Escalabilidade?

É interessante notar que tanto o Proto-Danksharding quanto o Danksharding não buscam melhorar a escalabilidade do Ethereum de forma direta. Nenhuma dessas atualizações muda a frequência de produção de blocos nem o tamanho máximo dos mesmos. A consequência disso é que o Ethereum em si continuará mantendo uma quantidade baixa de transações por segundo.

Apesar do que sugerem os nomes dessas atualizações, nenhuma delas é realmente uma solução de sharding.

O sharding se refere a uma arquitetura de banco de dados, onde a totalidade dos dados é dividida em fragmentos chamados shards, que podem ser modificados de forma independente. No Ethereum, isso se traduz na capacidade de dividir os validadores em grupos, permitindo que processem transações em paralelo. Atualmente, todos os validadores atribuídos a um slot se dedicam a validar a totalidade do bloco proposto, e o estado global é único, não estando dividido em shards. Isso, essencialmente, não mudaria com o Danksharding. Mas essa será uma história para outro momento!

Os verdadeiros beneficiados de tudo isso são os rollups, que podem se concentrar em processar grandes quantidades de transações e manter seus custos baixos ao contar com maior disponibilidade de blobspace. Essa é a verdadeira (e atual) estratégia do Ethereum: o que o próprio Vitalik chamou de rollup-centric roadmap.

Notas de Encerramento

Fica claro que ainda há muito a ser feito. O Ethereum pretende ser muito mais que uma blockchain, e sim tornar-se a infraestrutura para um futuro em que os rollups sejam protagonistas.

O caminho a percorrer ainda é longo, e há desafios muito interessantes pela frente. Assim como outras blockchains, o Ethereum é um sistema em constante evolução, e nos próximos anos certamente testemunharemos uma série de mudanças revolucionárias. A história da blockchain continua sendo escrita ao vivo, e é importante entender onde estão os problemas que, como comunidade, ainda precisamos resolver.

---

Este artigo faz parte de uma colaboração para a criação de conteúdo educativo sobre Ethereum entre Space Dev e ETH Kipu. Agradecemos a Juan Manuel Sobral por facilitar este encontro e, muito especialmente, a Franco Mangone pela redação do artigo.