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

Esquerda: uso de blob finalmente aumentando para a meta de 3 por bloco graças às Blobscrições. Direita: taxas de blob entrando em "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, o trabalho importante de escalabilidade, tanto no aumento do número de blobs como na melhoria da capacidade dos rollups de aproveitar ao máximo cada blob, continuará a ocorrer, mas será mais incremental. As mudanças relacionadas com a 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 está lentamente a mudar, e continuará a mudar 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 vai o Ethereum a partir daqui?

O futuro da escalabilidade do Ethereum

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

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

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

EIP-4844 (também conhecido como “blobs”) não nos dá amostragem de disponibilidade de dados. Mas configura a estrutura básica de tal forma que, a partir daqui, a amostragem de disponibilidade de dados pode ser introduzida e o número de blobs pode ser aumentado nos bastidores, tudo isso sem qualquer envolvimento de usuários ou aplicativos. Na verdade, a única “hard fork” necessária é uma simples alteração de parâmetro.

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

1. Capacidade de bloco progressivamente crescente, 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 fazer melhor uso do espaço de dados que temos

Dar vida à DAS

A próxima etapa provavelmente será uma versão simplificada do DAS chamada PeerDASNo 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 dado, pergunta a um dos pares que sabe ser responsável por armazenar esse dado.

Se cada nó precisar de baixar e armazenar 1/8 de todos os dados, então o PeerDAS permite-nos 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 validadores profissionais continuam a baixar blobs completos, e os validadores individuais apenas baixam 1/8 dos dados.

Além disso, EIP-7623(ou alternativas comoPreços 2D) pode ser usado para impor limites mais rigorosos 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 destino do bloco quanto o limite de gás L1. A longo prazo, mais complicado protocolos 2D DASpermitirá que avancemos até ao fim e aumentemos ainda mais o espaço do blob.

Melhorando L2s

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

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

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

Ingenuamente, uma transação ocupa cerca de 180 bytes de dados. No entanto, existem uma série de técnicas de compressãoque pode ser utilizadopara reduzir esse tamanho ao longo de várias etapas; com compressão ótima, 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 no L2 no caso normal. Para os EVMs, o plasma não pode proteger todas as moedas. Mas as construções inspiradas no plasma podem proteger a maioria das moedas. E construções muito mais simples do que o plasma podem melhorar muito o validiumsde hoje. Os L2s que não estão dispostos a colocar todos os seus dados on-chain devem explorar essas técnicas.

1. Continue a melhorar nas restrições relacionadas com a execução

Uma vez ativado o hard fork Dencun, tornando os rollups configurados para usar os blobs que introduziu 100x mais baratos. uso no Baserollup aumentou imediatamente:

Isso, por sua vez, levou a Base a atingir seu próprio limite de gás interno, causando taxas para aumentar inesperadamente. Isso levou a uma compreensão mais generalizada 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; rollups poderiam implementaralgo como EIP-648Mas tão importante comoarmazenamento, e efeitos de interaçãoentre computação e armazenamento. Este é um desafio de engenharia importante para rollups.

1. Continuar a melhorar a segurança

Ainda estamos longe de um mundo onde os rollups são verdadeiramente protegidos pelo código. Na verdade, de acordo com l2beatapenas estes cinco, dos quais apenas Arbitrum é totalmente EVM, chegaram sequero que eu chamei de "fase 1".

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

Os padrões do ecossistema precisam tornar-se mais rigorosos: até agora, temos sido tolerantes e aceitado qualquer projeto, desde que afirme estar 'num caminho para a descentralização'. Até o final do ano, acredito que nossos padrões devem aumentar e só devemos considerar um projeto como um rollup se ele realmente tiver atingido pelo menos a fase 1.

Depois disto, podemos avançar com cautela para a fase 2: um mundo onde os rollups são verdadeiramente suportados por código, e um conselho de segurança só pode intervir se o código 'discordar de si mesmo' de forma comprovada (por exemplo, aceita duas raízes de estado incompatíveis, ou duas implementações diferentes dão respostas diferentes). Um caminho para fazer isto com segurança éutilizar várias implementações de provador.

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

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

Hoje, eu argumentaria que estamos decididamente no lado direito de desaceleração desta curva-S. Há duas semanas, as duas maiores mudanças na blockchain do Ethereum - a mudança para prova de participação e a re-arquitetura para blobs - já estão atrás de nós. Mudanças adicionais ainda são significantes (por exemplo, Árvores Verkle, finalidade de slot único, abstração de conta no protocolo) mas não são tão drásticas como o são o 'proof of stake' e o 'sharding'. Em 2022, o Ethereum foi como um avião a substituir os seus motores em pleno voo. Em 2023, estava a substituir as suas asas. A transição para a árvore Verkle é a única verdadeiramente significativa que resta (e já temos testnets para isso); as outras são mais como a substituição de uma barbatana.

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

O que isso significa para as aplicações e utilizadores?

Os primeiros dez anos do Ethereum foram em grande parte uma fase de treinamento: o objetivo tem sido lançar o Ethereum L1 e as aplicações têm ocorrido principalmente dentro de um pequeno grupo de entusiastas. Muitos argumentaram que a falta de aplicações em grande escala nos últimos dez anos prova que a criptografia é inútil. Sempre argumentei contra isso: praticamente todas as aplicações de criptografia que não são especulação financeira dependem de taxas baixas - e, portanto, enquanto tivermos taxas altas, não devemos nos surpreender que vejamos principalmente especulação financeira!

Agora que temos blobs, esta restrição chave que nos tem impedido ao longo deste tempo está começando a desaparecer. As taxas finalmente sã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 cêntimos por transaçãofinalmente a tornar-se realidade. Ainda não estamos totalmente fora do bosque: as taxas podem ainda aumentar se a utilização crescer demasiado rapidamente e precisamos de continuar a trabalhar arduamente para escalar os blobs (e escalar separadamente os rollups) ainda mais nos próximos anos. Mas estamos a ver a luz ao fundo do… err….. bosque escuro.

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 aplicações que claramente não eram utilizáveis em grande escala, desde que funcionassem como protótipos e fossem razoavelmente descentralizadas. Hoje, temos todas as ferramentas de que precisaremos e, de fato, a maioria das ferramentas que sempre teremos, para construir aplicações que sejam simultaneamente cypherpunke fácil de usar. E assim devemos sair e fazê-lo.

Muitos estão a aceitar o desafio. A carteira Daimo está a descrever-se explicitamente comoVenmo no Ethereum, visando combinar a conveniência do Venmo com a descentralização do Ethereum. Na esfera social descentralizada, 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 uma excelente experiência do usuário. Ao contrário das ondas de hype anteriores do "social fi", o usuário médio do Farcaster não está lá para apostar - passando no teste-chave para uma aplicação de cripto ser verdadeiramente sustentável.

Esta publicação foi enviada no cliente principal do Farcaster, Warpcast, e esta captura de ecrã foi tirada 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 governação.

As aplicações construídas ou mantidas hoje devem ser projetadas tendo em mente o Ethereum dos anos 2020

O ecossistema 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 da atividade ENS ainda está na camada 1. A maioria das emissões de tokens acontece na camada 1, sem consideração séria para garantir que os tokens ponte na camada 2 estejam disponíveis (por exemplo, ver este fã da criptomoeda ZELENSKYY) apreciando as doações contínuas da moeda à Ucrânia, mas reclamando que as taxas da L1 tornam-na muito cara). Além da escalabilidade, também estamos atrasados na privacidade: POAPssão todos publicamente na cadeia, provavelmente a escolha certa para alguns casos de uso, mas muito subótimos para outros. A maioria das DAOs e Bolsas de Gitcoin, ainda usam votação totalmente transparente na cadeia, tornando-osaltamente vulnerável à suborno(incluindo airdrops retroativos), e isso foi demonstrado distorcer significativamente os padrões de contribuição. Hoje, os ZK-SNARKs existem há anos e ainda muitas aplicações nem sequer começaram ausá-los corretamente.

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

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

Conclusões

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

Aviso Legal：

1. Este artigo é reproduzido a partir de [ Vitalik], Todos os direitos de autor pertencem ao autor original [Vitalik]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as 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. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.