No dia 13 de março, o hard fork Dencun foi ativado, possibilitando uma das funcionalidades mais aguardadas do Ethereum: proto-danksharding (também conhecido como EIP-4844, aka blobs). Inicialmente, o fork reduziu as taxas de transação de rollups em mais de 100 vezes, já que os blobs eram quase gratuitos. No último dia, finalmente vimos os blobs aumentarem em volume e o mercado de taxas se ativou à medida que o protocolo de blobscrições começou a usá-los. Os blobs não são gratuitos, mas continuam sendo muito mais baratos do que os calldata.

À esquerda: uso de blobs finalmente disparando para a meta de 3 por bloco graças às Blobscrições. À direita: taxas de blobs "entrando no modo de descoberta de preço" como resultado. Fonte: https://dune.com/0xRob/blobs.

Este marco representa uma transição chave no roteiro de longo prazo do Ethereum: os blobs são o momento em que a escalabilidade do Ethereum deixou de ser um problema de “zero a um” e se tornou um problema de “um para N”. A partir daqui, importantes trabalhos de escalabilidade, tanto no aumento do número de blobs quanto na melhoria da capacidade dos rollups de aproveitar ao máximo cada blob, continuarão a acontecer, mas de forma mais incremental. As mudanças relacionadas à escalabilidade no paradigma fundamental de como o Ethereum como ecossistema opera estão cada vez mais atrás de nós. Além disso, a ênfase já está lentamente se deslocando, e continuará a se deslocar lentamente, dos problemas de L1, como PoS e escalabilidade, para problemas mais próximos da camada de aplicação. A questão-chave que este post abordará é: para onde o Ethereum vai a partir daqui?

O futuro da escalabilidade do Ethereum

Nos últimos anos, temos visto o Ethereum lentamente mudar para se tornar um ecossistema centrado em L2. Principais aplicativos começaram a migrar do L1 para o L2, os pagamentos estão começando a ser baseados em L2 por padrão, e as carteiras estão começando a construir sua experiência do usuário em torno do novo ambiente multi-L2.

Desde o início, uma peça-chave do roadmap centrado em rollups foi a ideia de um espaço de disponibilidade de dados separado: uma seção especial de espaço em um bloco, ao qual a EVM não teria acesso, que poderia armazenar dados para projetos de camada 2, como rollups. Como este espaço de dados não é acessível pela EVM, ele pode ser transmitido separadamente de um bloco e verificado separadamente de um bloco. Eventualmente, ele pode ser verificado com uma tecnologia chamada amostragem de disponibilidade de dados, o que permite que cada nó verifique se os dados foram publicados corretamente apenas verificando aleatoriamente algumas pequenas amostras. Uma vez que isso é implementado, o espaço do bloco poderia ser ampliado significativamente; o objetivo final é de 16 MB por slot (~1,33 MB por segundo).

Amostragem de disponibilidade de dados: cada nó só precisa baixar uma pequena parte dos dados para verificar a disponibilidade do todo.

EIP-4844 (também conhecido como “blobs”) não nos fornece amostragem de disponibilidade de dados. Mas ele configura a estrutura básica de tal maneira que, a partir de agora, a amostragem de disponibilidade de dados pode ser introduzida e a contagem de blobs pode ser aumentada nos bastidores, tudo sem qualquer envolvimento dos usuários ou aplicativos. Na verdade, o único “hard fork” necessário é uma simples mudança de parâmetro.

Existem duas vertentes de desenvolvimento que precisarão continuar a partir daqui:

1. Aumentando progressivamente a capacidade do blob, trazendo eventualmente à vida a visão completa da amostragem de disponibilidade de dados com 16 MB por slot de espaço de dados
2. Melhorar L2s para aproveitar melhor o espaço de dados que temos

Dando vida ao DAS

A próxima etapa provavelmente será uma versão simplificada do DAS chamadaPeerDASNo PeerDAS, cada nó armazena uma fração significativa (por exemplo, 1/8) de todos os dados de blob, e os nós mantêm conexões com muitos pares na rede p2p. Quando um nó precisa amostrar um determinado pedaço de dados, ele pergunta a um dos pares que sabe que é responsável por armazenar esse pedaço.

Se cada nó precisa baixar e armazenar 1/8 de todos os dados, então o PeerDAS nos permite escalar teoricamente os blobs em 8x (bem, na verdade 4x, porque perdemos 2x devido à redundância da codificação de apagamento). O PeerDAS pode ser implementado ao longo do tempo: podemos ter uma fase em que os stakers profissionais continuam baixando blobs completos, e os stakers solo baixam apenas 1/8 dos dados.

Além disso, EIP-7623(ou alternativas comoPreços 2D) pode ser usado para impor limites mais rígidos ao tamanho máximo de um bloco de execução (ou seja, as “transações regulares” em um bloco), o que torna mais seguro aumentar tanto o objetivo de blob quanto o limite de gás L1. A longo prazo, mais complicadoprotocolos DAS 2Dnos permitirá ir até o fim e aumentar ainda mais o espaço do blob.

Melhorando L2s

Existem quatro lugares-chave nos quais os protocolos de camada 2 hoje podem melhorar.

1. Usando bytes de forma mais eficiente com compressão de dados

Meu esboço-em-uma-imagem de compressão de dadoscontinua disponível aqui;

De forma ingênua, uma transação ocupa cerca de 180 bytes de dados. No entanto, existem uma série de técnicas de compressão que pode ser usadopara reduzir esse tamanho ao longo de várias etapas; com compressão ideal, poderíamos potencialmente chegar a menos de 25 bytes por transação.

1. Técnicas de dados otimistas que garantem L2s usando apenas o L1 em situações excepcionais

Plasmaé uma categoria de técnicas que permite obter segurança equivalente a rollup para algumas aplicações, mantendo os dados na L2 no caso normal. Para os EVMs, o plasma não pode proteger todas as moedas. Mas construções inspiradas no Plasma podem proteger a maioria das moedas. E construções muito mais simples do que o Plasma podem melhorar significativamente o validiumsde hoje. L2s que não estão dispostos a colocar todos os seus dados on-chain devem explorar tais técnicas.

1. Continue melhorando as restrições relacionadas à execução

Uma vez que o hard fork Dencun foi ativado, fazendo com que os rollups configurados usem os blobs que ele introduziu 100x mais baratos. uso no Baserollup disparou imediatamente:

Isso, por sua vez, levou a Base atingindo seu próprio limite de gás interno, causando taxas para aumentar inesperadamenteIsso levou a uma compreensão mais ampla de que o espaço de dados do Ethereum não é a única coisa que precisa ser dimensionada: os rollups também precisam ser dimensionados internamente.

Parte disso é a paralelização; os rollups poderiam implementaralgo como EIP-648. Mas tão importante quanto éarmazenamento, e efeitos de interaçãoentre computação e armazenamento. Este é um desafio de engenharia importante para rollups.

1. Continuar melhorando a segurança

Ainda estamos longe de um mundo onde rollups são verdadeiramente protegidos por código. Na verdade, de acordo com l2beatapenas esses cinco, dos quais apenas Arbitrum é full-EVM, chegaram até mesmoo que eu chamei de 'estágio 1'.

Isso precisa ser enfrentado de frente. Embora atualmente não estejamos no ponto em que podemos ter confiança suficiente no código complexo de um verificador de EVM otimista ou baseado em SNARK, estamos absolutamente no ponto em que podemos chegar até a metade do caminho e ter conselhos de segurança que podem reverter o comportamento do código apenas com um alto limiar (por exemplo, eu propus 6 de 8; Arbitrum está fazendo 9 de 12).

Os padrões do ecossistema precisam se tornar mais rígidos: até agora, temos sido tolerantes e aceitado qualquer projeto, desde que afirme estar "em um caminho para a descentralização". Até o final do ano, acho que nossos padrões devem aumentar e só devemos considerar um projeto como um rollup se ele tiver realmente alcançado pelo menos o estágio 1.

Depois disso, podemos avançar com cautela para a etapa 2: um mundo onde os rollups realmente são respaldados por código, e um conselho de segurança só pode intervir se o código "provavelmente discordar de si mesmo" (por exemplo, aceitar duas raízes de estado incompatíveis ou duas implementações diferentes darem respostas diferentes). Um caminho para fazer isso com segurança éusar várias implementações de provadores.

O que isso significa para o desenvolvimento do Ethereum de forma mais ampla?

Em uma apresentação na ETHCC no verão de 2022, Eu fiz uma apresentação descrevendo o estado atual do desenvolvimento do Ethereum como uma curva em S: estamos entrando em um período de transição muito rápida e, após essa transição rápida, o desenvolvimento mais uma vez desacelerará à medida que o L1 se solidifica e o desenvolvimento se reenfoca na camada do usuário e da aplicação.

Hoje, eu argumentaria que estamos decididamente no lado direito e desacelerado desta curva em S. Até duas semanas atrás, as duas maiores mudanças na blockchain do Ethereum - a mudança para o proof of stake e a reestruturação para blobs - estão atrás de nós. Mudanças adicionais ainda são significativas (por exemplo, árvores Verkle, finalidade de um único slot, abstração de conta no protocolo) , mas não são drásticas no mesmo grau que a prova de participação e o particionamento. Em 2022, o Ethereum foi como um avião substituindo seus motores em pleno voo. Em 2023, estava substituindo suas asas. A transição da árvore Verkle é a principal mudança verdadeiramente significativa restante (e já temos testnets para isso); as outras são mais como substituir um estabilizador vertical.

O objetivo do EIP-4844 era fazer uma única alteração grande e única, a fim de preparar os rollups para a estabilidade a longo prazo. Agora que os blobs estão fora, uma atualização futura para o danksharding completo com blobs de 16 MB e até mesmo a mudança da criptografia paraSTARKs sobre um campo goldilocks de 64 bits, pode acontecer sem exigir nenhuma ação adicional de rollups e usuários. Ele também reforça um importante precedente: que o processo de desenvolvimento do Ethereum é executado de acordo com um roteiro bem estabelecido e compreendido há muito tempo, e as aplicações (incluindo L2s) que são construídas com a ideia do 'novo Ethereum' em mente obtêm um ambiente que é estável a longo prazo.

O que isso significa para aplicativos e usuários?

Os primeiros dez anos do Ethereum foram em grande parte uma fase de treinamento: o objetivo foi colocar o Ethereum L1 em funcionamento, e as aplicações ocorreram principalmente dentro de um pequeno grupo de entusiastas. Muitos argumentaram que a falta de aplicações em larga escala nos últimos dez anos prova que o cripto é inútil. Eu sempre argumentei contra isso: praticamente toda aplicação cripto que não seja especulação financeira depende de taxas baixas - e, portanto, enquanto tivermos taxas altas, não devemos nos surpreender que vejamos principalmente especulação financeira!

Agora que temos blobs, essa restrição chave que tem nos segurado todo esse tempo está começando a desaparecer. As taxas finalmente estão muito mais baixas; minha declaração de sete anos atrás que a internet do dinheiro não deve custar mais do que cinco centavos por transaçãofinalmentetornando-se realidade. Não estamos totalmente fora do perigo: as taxas ainda podem aumentar se o uso crescer muito rapidamente, e precisamos continuar trabalhando duro para escalar blobs (e escalar rollups separadamente) ainda mais nos próximos anos. Mas estamos vendo a luz no fim da... err... floresta escura.

O que isso significa para os desenvolvedores é simples: não temos mais desculpas. Até alguns anos atrás, estávamos estabelecendo um padrão baixo, construindo aplicativos que claramente não eram utilizáveis em escala, desde que funcionassem como protótipos e fossem razoavelmente descentralizados. Hoje, temos todas as ferramentas de que precisaremos, e de fato a maioria das ferramentas que sempre teremos, para construir aplicativos que são simultaneamente cypherpunke fácil de usar. E assim devemos sair e fazer isso.

Muitos estão se levantando para o desafio. A carteira Daimo está se descrevendo explicitamente comoVenmo no Ethereum, visando combinar a conveniência do Venmo com a descentralização do Ethereum. Na esfera social descentralizada, o Farcaster está fazendo um bom trabalho ao combinar uma descentralização genuína (por exemplo, veja este guiasobre como construir seu próprio cliente alternativo) com excelente experiência do usuário. Ao contrário das ondas anteriores de hype de 'fi social', o usuário médio do Farcaster não está lá para apostar - passando no teste-chave para uma aplicação de criptomoeda ser verdadeiramente sustentável.

Esta postagem foi enviada no cliente principal Farcaster, Warpcast, e esta captura de tela foi feita a partir do Farcaster alternativo +LenteclienteFirefly.

Estes são sucessos que precisamos construir e expandir para outras esferas de aplicação, incluindo identidade, reputação e governança.

Aplicações construídas ou mantidas hoje devem ser projetadas tendo em mente o Ethereum da década de 2020

O ecossistema do Ethereum ainda tem um grande número de aplicações que operam em torno de um fluxo de trabalho fundamentalmente 'Ethereum dos anos 2010'. A maioria das atividades da ENS ainda está na camada 1. A maioria das emissões de tokens ocorre na camada 1, sem considerar seriamente se os tokens pontes nas camadas 2 estão disponíveis (por exemplo, vejaesse fã da criptomoeda ZELENSKYY) apreciando as doações contínuas da moeda para a Ucrânia, mas reclamando que as taxas da L1 tornam isso muito caro). Além da escalabilidade, também estamos atrasados em relação à privacidade: POAPssão todos públicos na cadeia, provavelmente a escolha certa para alguns casos de uso, mas muito subótimo para outros. A maioria dos DAOs e Bolsas Gitcoin, ainda usam votação totalmente transparente em cadeia, tornando-osaltamente vulnerável à suborno(incluindo airdrops retroativos), e isso tem sido mostrado para distorcer fortemente os padrões de contribuição. Hoje, os ZK-SNARKs existem há anos, e no entanto muitas aplicações nem mesmo começaram ausá-los corretamente.

Estas são todas equipas trabalhadoras que têm de lidar com grandes bases de utilizadores existentes, por isso não lhes censuro por não atualizarem simultaneamente para a última onda de tecnologia. Mas em breve, esta atualização terá de acontecer. Aqui estão algumas diferenças-chave entre 'um fluxo de trabalho fundamentalmente de Ethereum dos anos 2010' e 'um fluxo de trabalho fundamentalmente de Ethereum dos anos 2020'.

Basicamente, o Ethereum não é mais apenas um ecossistema financeiro. É uma substituição completa para grandes partes da "tecnologia centralizada", e até mesmo fornece algumas coisas que a tecnologia centralizada não faz (por exemplo, aplicações relacionadas à governança). E precisamos construir com esse ecossistema mais amplo em mente.

Conclusões

• Ethereum está no processo de uma mudança decisiva de uma era de "progresso muito rápido da L1" para uma era em que o progresso da L1 ainda será muito significativo, mas um pouco mais suave e menos disruptivo para as aplicações.
• Ainda precisamos concluir a escalabilidade. Este trabalho será mais nos bastidores, mas continua importante.
• Os desenvolvedores de aplicativos não estão mais construindo protótipos; estamos construindo ferramentas para que muitos milhões de pessoas usem. Em todo o ecossistema, precisamos reajustar totalmente as mentalidades de acordo.
• O Ethereum evoluiu de ser apenas um ecossistema financeiro para uma pilha de tecnologia descentralizada muito mais abrangente e independente. Em todo o ecossistema, precisamos ajustar completamente as mentalidades de acordo com isso também.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Vitalik], Todos os direitos autorais pertencem ao autor original [Vitalik]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas 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 Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.