Estou sentado aqui escrevendo isso no último dia de uma interoperação de desenvolvedores do Ethereum no Quênia, onde fizemos um grande progresso na implementação e resolução de detalhes técnicos de importantes melhorias futuras do Ethereum, especialmentePeerDAS, o transição de árvore Verklee abordagens descentralizadas para armazenar histórico no contexto deEIP 4444. Do meu próprio ponto de vista, parece que o ritmo de desenvolvimento do Ethereum e nossa capacidade de lançar recursos grandes e importantes que melhoram significativamente a experiência dos operadores de nós e dos usuários (L1 e L2) estão aumentando.

Equipes de clientes Ethereum trabalhando juntas para lançar a rede de desenvolvimento Pectra.

Dada essa maior capacidade técnica, uma pergunta importante a se fazer é: estamos construindo em direção aos objetivos certos? Uma sugestão para pensar sobre isso é uma recente série de tweets infelizes do desenvolvedor principal de Geth, Peter Szilagyi, há muito tempo.

Essas são preocupações válidas. São preocupações que muitas pessoas na comunidade do Ethereum têm expressado. São preocupações que eu pessoalmente tive em muitas ocasiões. No entanto, também não acho que a situação esteja tão desesperadora quanto os tweets de Peter implicam; pelo contrário, muitas das preocupações já estão sendo abordadas por recursos de protocolo que já estão em andamento, e muitas outras podem ser abordadas por ajustes muito realistas no roadmap atual.

Para ver o que isso significa na prática, vamos passar pelas três exemplos que Peter forneceu, um por um. O objetivo não é focar em Peter especificamente; são preocupações que são amplamente compartilhadas entre muitos membros da comunidade, e é importante abordá-las.

MEV, e dependência do construtor

No passado, os blocos do Ethereum eram criados por mineradores, que usavam um algoritmo relativamente simples para criar blocos. Os usuários enviam transações para uma rede p2p pública frequentemente chamada de “mempool” (ou “txpool”). Os mineradores escutam o mempool e aceitam transações que são válidas e pagam taxas. Eles incluem as transações que podem e, se não houver espaço suficiente, priorizam as de maior taxa primeiro.

Este era um sistema muito simples e amigável à descentralização: como minerador, você pode simplesmente executar o software padrão e obter os mesmos níveis de receita de taxa de um bloco que você poderia obter de fazendas de mineração altamente profissionais. Por volta de 2020, no entanto, as pessoas começaram a explorar o que era chamado de valor extrativo do minerador (MEV): receita que só poderia ser obtida executando estratégias complexas que estão cientes das atividades acontecendo dentro de vários protocolos defi.

Por exemplo, considere trocas descentralizadas como Uniswap. Suponha que, no momento T, a taxa de câmbio USD/ETH - nas trocas centralizadas e na Uniswap - seja $3000. No momento T+11, a taxa de câmbio USD/ETH nas trocas centralizadas sobe para $3005. Mas o Ethereum ainda não teve seu próximo bloco. No momento T+12, ele o tem. Quem cria o bloco pode fazer sua primeira transação ser uma série de compras na Uniswap, comprando todo o ETH disponível na Uniswap a preços de $3000 a $3004. Esta é uma receita extra e é chamada de MEV. Aplicações que não sejam DEXes têm seus próprios análogos para esse problema. Flash Boys 2.0 paperpublicado em 2019 entra em detalhes sobre isso.

Um gráfico do documento Flash Boys 2.0 que mostra a quantidade de receita capturável usando os tipos de abordagens descritas acima.

O problema é que isso quebra a história de por que a mineração (ou, após 2022, a proposição de bloco) pode ser “justa”: agora, grandes atores que têm uma melhor capacidade de otimizar esses tipos de algoritmos de extração podem obter um retorno melhor por bloco.

Desde então, houve um debate entre duas estratégias, que chamarei de minimização de MEV e quarentena de MEV. A minimização de MEV ocorre em duas formas: (i) trabalhar agressivamente em alternativas livres de MEV para Uniswap (por exemplo, Troca de vacas) e (ii) construir técnicas in-protocolo, como mempools criptografados, que reduzem as informações disponíveis para os produtores de blocos e, assim, reduzem a receita que eles podem capturar. Em particular, mempools criptografados impedem estratégias como ataques de sandwich, que colocam transações logo antes e depois das negociações dos usuários para explorá-los financeiramente ("front-running").

A quarentena de MEV funciona aceitando MEV, mas tentando limitar seu impacto na centralização de staking, separando o mercado em dois tipos de atores: os validadores são responsáveis por atestar e propor blocos, mas a tarefa de escolher o conteúdo do bloco é terceirizada para construtores especializados através de um protocolo de leilão. Os apostadores individuais agora não precisam mais se preocupar em otimizar a arbitragem de defi eles mesmos; eles simplesmente se juntam ao protocolo de leilão e aceitam a oferta mais alta. Isso é chamado de separação de proponente/construtor (PBS). Essa abordagem tem precedentes em outras indústrias: uma das principais razões pelas quais os restaurantes conseguem permanecer tão descentralizados é que muitas vezes contam com um conjunto bastante concentrado de fornecedores para várias operações que têm economias de escala consideráveis. Até agora, o PBS tem sido razoavelmente bem-sucedido em garantir que pequenos validadores e grandes validadores estejam em um campo de jogo justo, pelo menos no que diz respeito ao MEV. No entanto, cria outro problema: a tarefa de escolher quais transações serão incluídas se torna mais concentrada.

Minha opinião sobre isso sempre foi que a minimização do MEV é boa e devemos buscá-la (eu pessoalmente uso o Cowswap regularmente!) - embora os mempools criptografados tenham muitos desafios, mas a minimização do MEV provavelmente será insuficiente; O MEV não vai descer a zero, nem mesmo perto de zero. Por isso, precisamos de algum tipo de quarentena MEV também. Isso cria uma tarefa interessante: como tornar a "caixa de quarentena MEV" a menor possível? Como dar aos construtores o menor poder possível, ao mesmo tempo em que os mantemos capazes de absorver o papel de otimizar a arbitragem e outras formas de coleta de MEV?

Se os construtores têm o poder de excluir transações de um bloco inteiramente, existem ataques que podem surgir bastante facilmente. Suponha que você tenha um posição de dívida colateralizada (CDP)em um protocolo defi, apoiado por um ativo cujo preço está caindo rapidamente. Você quer aumentar sua garantia ou sair do CDP. Os construtores maliciosos poderiam tentar conluio para recusar a inclusão de sua transação, atrasando-a até que os preços caiam o suficiente para que eles possam liquidar à força seu CDP. Se isso acontecer, você teria que pagar uma grande penalidade, e os construtores receberiam uma grande parte dela. Então, como podemos impedir que os construtores excluam transações e realizem esse tipo de ataques?

Aqui é onde entram as listas de inclusão.

Origem: esta postagem ethresear.ch.

Listas de inclusão permitem que os proponentes de blocos (ou seja, validadores) escolham transações que são necessárias para entrar no bloco. Os construtores ainda podem reordenar transações ou inserir as próprias, mas devem incluir as transações do proponente. Eventualmente, listas de inclusão foram modificadaspara restringir o próximo bloco em vez do bloco atual. Em qualquer caso, eles retiram a capacidade do construtor de empurrar transações para fora do bloco completamente.

Tudo isso foi um grande buraco de coelho de antecedentes complicados. Mas MEV é um problema complicado; até a descrição acima deixa de fora muitas nuances importantes. Como diz o ditado, 'você pode não estar procurando MEV, mas MEV está procurando por você'. Os pesquisadores do Ethereum já estão bastante alinhados com o objetivo de 'minimizar a caixa de quarentena', reduzindo ao máximo o dano que os construtores podem causar (por exemplo, excluindo ou atrasando transações como forma de atacar aplicativos específicos) quanto possível.

Dito isso, acho que podemos ir ainda mais longe. Historicamente, as listas de inclusão frequentemente foram concebidas como um recurso especial "à parte": normalmente, você não pensaria nelas, mas no caso de construtores maliciosos começarem a fazer coisas loucas, elas oferecem um "segundo caminho". Essa atitude é refletida nas decisões de design atuais: no EIP atual, o limite de gás de uma lista de inclusão é de cerca de 2,1 milhões. Mas podemos fazer uma mudança filosófica em como pensamos sobre listas de inclusão: pense na lista de inclusão como sendo o bloco, e pense no papel do construtor como sendo uma função secundária de adicionar algumas transações para coletar MEV. E se forem os construtores que tiverem o limite de gás de 2,1 milhões?

Acho que as ideias nesta direção - realmente empurrando a caixa de quarentena para ser o mais pequena possível - são realmente interessantes, e estou a favor de seguir nessa direção. Isso é uma mudança da “filosofia da era de 2021”: na filosofia da era de 2021, estávamos mais entusiasmados com a ideia de que, uma vez que agora temos construtores, podemos “sobrecarregar” sua funcionalidade e fazê-los servir aos usuários de maneiras mais complicadas, por exemplo, apoiando mercados de taxas ERC-4337Nesta nova filosofia, as partes de validação de transações do ERC-4337 teriam que ser consagradas no protocolo. Felizmente, a equipe do ERC-4337 já está @yoav/AA-roadmap-May-2024#Native-AA---um-roadmap-modular">cada vez mais entusiasmado com esta direção.

Resumo: O pensamento MEV já estava voltando na direção de capacitar os produtores de blocos, incluindo dar aos produtores de blocos a autoridade para garantir diretamente a inclusão das transações dos usuários. As propostas de abstração de contas já estavam voltando na direção de remover a dependência de relays centralizados e até mesmo de bundlers. No entanto, há um bom argumento de que não estamos indo longe o suficiente, e acho que a pressão para fazer o processo de desenvolvimento avançar nessa direção é altamente bem-vinda.

Participação em liquidez

Hoje, os validadores individuais representam uma porcentagem relativamente pequena de todas as apostas de Ethereum, e a maioria das apostas é feita por vários provedores - alguns operadores centralizados e outros DAOs, como Lido e RocketPool.

Eu fiz minha própria pesquisa - várias pesquisas [1] [2], pesquisas, conversas presenciais, fazendo a pergunta 'por que você - especificamente você - não está fazendo staking solo hoje?' Para mim, um ecossistema robusto de staking solo é de longe o resultado preferido para o staking do Ethereum, e uma das melhores coisas sobre o Ethereum é que na verdade tentamos apoiar um ecossistema robusto de staking solo em vez de apenas nos rendermos à delegação. No entanto, estamos longe desse resultado. Em minhas enquetes e pesquisas, há algumas tendências consistentes:

1. A grande maioria das pessoas que não estão apostando sozinhas citam como principal motivo o mínimo de 32 ETH.
2. Dentre aqueles que citam outras razões, a mais alta é o desafio técnico de executar e manter um nó validador.
3. A perda da disponibilidade instantânea de ETH, os riscos de segurança das chaves privadas "quentes" e a perda da capacidade de participar simultaneamente em protocolos de defi são preocupações significativas, mas menores.

Os principais motivos pelos quais as pessoas não estão fazendo staking solo, de acordo com as pesquisas da Farcaster.

Existem duas questões-chave para a pesquisa de staking resolver:

1. Como resolvemos essas preocupações?
2. Se, apesar das soluções eficazes para a maioria dessas preocupações, a maioria das pessoas ainda não quiser fazer staking solo, como mantemos o protocolo estável e robusto contra ataques apesar desse fato?

Muitos itens de pesquisa e desenvolvimento em andamento têm como objetivo resolver precisamente esses problemas:

1. Árvores VerklemaisEIP-4444permitir que os nós de staking funcionem com requisitos de disco rígido muito baixos. Além disso, eles permitem que os nós de staking sincronizem quase instantaneamente, simplificando muito o processo de configuração, bem como operações como a troca de uma implementação para outra. Eles também tornam os clientes leves do Ethereum muito mais viáveis, reduzindo a largura de banda de dados necessária para fornecer provas para cada acesso de estado.
2. Pesquisar(por exemplo, essas propostas)em maneiras de permitir um conjunto de validadores muito maior (possibilitando mínimos de aposta muito menores) ao mesmo tempo em que reduz a sobrecarga do nó de consenso. Essas ideias podem ser implementadas como parte definalidade de slot únicoFazer isso também tornaria os clientes leves mais seguros, pois eles seriam capazes de verificar o conjunto completo de assinaturas em vez de depender decomitês de sincronização).
3. As otimizações contínuas do cliente Ethereum continuam reduzindo o custo e a dificuldade de executar um nó validador, apesar do crescimento da história.
4. Pesquisa sobre penalidades de limitepoderia potencialmente mitigar preocupações em torno do risco de chave privada e permitir que validadores apostem simultaneamente seu ETH em protocolos de defi, se assim desejarem.
5. 0x01 Credenciais de saquepermitir que os stakers definam um endereço ETH como seu endereço de saque. Isso torna as pools de staking descentralizadas mais viáveis, dando-lhes vantagem sobre as pools de staking centralizadas.

No entanto, mais uma vez, há mais que poderíamos fazer. É teoricamente possível permitir que os validadores retirem muito mais rapidamente: Casper FFG continua a ser seguro mesmo se o conjunto de validadores mudar em alguns por cento sempre que ele finaliza (ou seja, uma vez por época). Portanto, poderíamos reduzir muito mais o período de retirada se nos esforçássemos. Se quisermos reduzir consideravelmente o tamanho do depósito mínimo, poderíamos tomar uma decisão difícil de compensar em outras direções, por exemplo, se aumentarmos o tempo de finalidade em 4x, isso permitiria um@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">4x tamanho mínimo do depósito diminuído. A finalidade do slot único mais tarde limparia isso, movendo-se além do modelo de "cada validador participa de cada época" completamente.

Outra parte importante desta questão é a economia de staking. Uma questão-chave é: queremos que o staking seja uma atividade relativamente de nicho, ou queremos que todos ou quase todos apostem todos os seus ETH? Se todos estiverem apostando, qual é a responsabilidade que queremos que todos assumam? Se as pessoas acabarem simplesmente delegando essa responsabilidade por preguiça, isso poderá levar à centralização. Existem questões filosóficas importantes e profundas aqui. Respostas incorretas poderiam levar o Ethereum por um caminho de centralização e "recriar o sistema financeiro tradicional com etapas extras"; respostas corretas poderiam criar um exemplo brilhante de um ecossistema bem-sucedido com um conjunto amplo e diversificado de apostadores individuais e pools de staking altamente descentralizadas. Estas são questões que abordam a economia e os valores fundamentais do Ethereum, e portanto precisamos de uma participação mais diversificada aqui.

Requisitos de hardware dos nós

Muitas das questões-chave na descentralização do Ethereum acabam se resumindo a uma pergunta que definiu a política de blockchainpor uma década: quão acessível queremos tornar a execução de um nó e como?

Hoje, executar um nó é difícil. A maioria das pessoas não o faz. No laptop que estou usando para escrever este post, tenho um rethnó e ocupa 2,1 terabytes - já é o resultado de uma engenharia de software heróica e otimização. Eu precisei comprar um disco rígido extra de 4 TB para colocar no meu laptop a fim de armazenar esse nó. Todos nós queremos que executar um nó seja mais fácil. No meu mundo ideal, as pessoas poderiam executar nós em seus telefones.

Como escrevi acima, EIP-4444 e árvores Verkle são duas tecnologias-chave que nos aproximam desse ideal. Se ambos forem implementados, os requisitos de hardware de um nó poderiam plausivelmente eventualmente diminuir para menos de cem gigabytes e talvez para perto de zero se eliminarmos completamente a responsabilidade de armazenamento de histórico (talvez apenas para nós não de staking).Tipo 1 ZK-EVMsremoveria a necessidade de executar a computação do EVM você mesmo, pois você poderia simplesmente verificar uma prova de que a execução estava correta. No meu mundo ideal, empilhamos todas essas tecnologias juntas, e até as carteiras de extensão do navegador Ethereum (por exemplo, Metamask, Rabby) têm um nó integrado que verifica essas provas, faz amostragem de disponibilidade de dados e está satisfeito de que a cadeia está correta.

A visão descrita acima é muitas vezes chamada de "The Verge".

Tudo isso é conhecido e compreendido, até mesmo pelas pessoas que levantam preocupações sobre o tamanho do nó do Ethereum. No entanto, há uma preocupação importante: se estamos transferindo a responsabilidade de manter o estado e fornecer provas, isso não é um vetor de centralização? Mesmo que não possam trapacear fornecendo dados inválidos, isso não vai contra os princípios do Ethereum ao se tornar muito dependente deles?

Uma versão muito próxima desse problema é o desconforto de muitas pessoas em relação ao EIP-4444: se os nós regulares do Ethereum não precisam mais armazenar o histórico antigo, então quem precisa? Uma resposta comum é: certamente existem actores importantes suficientes (por exemplo, exploradores de blocos, exchanges, camadas 2) que têm o incentivo para manter esses dados, e em comparação com os 100 petabytes armazenados pela Wayback Machine, a cadeia Ethereum é pequena. Portanto, é ridículo pensar que qualquer história será realmente perdida.

No entanto, este argumento baseia-se na dependência de um pequeno número de atores grandes. Em meu taxonomia de modelos de confiança, é uma suposição de 1-de-N, mas o N é bastante pequeno. Isso tem seus riscos. Uma coisa que poderíamos fazer em vez disso é armazenar o histórico antigo em uma rede peer-to-peer, onde cada nó armazena apenas uma pequena porcentagem dos dados. Esse tipo de rede ainda faria cópias suficientes para garantir robustez: haveria milhares de cópias de cada pedaço de dados, e no futuro poderíamos usar codificação de apagamento (realisticamente, colocando o histórico em EIP-4844blobs de estilo, que já possuem codificação de apagamento incorporada) para aumentar ainda mais a robustez.

Os blobs têm codificação de apagamento dentro dos blobs e entre os blobs. A maneira mais fácil de criar armazenamento ultra-robusto para toda a história do Ethereum pode muito bem ser apenas colocar blocos de beacon e execução nos blobs.Fonte da imagem: codex.storage

Por muito tempo, este trabalho tem sido deixado de lado; Portal Networkexiste, mas realisticamente não recebeu o nível de atenção proporcional à sua importância no futuro do Ethereum. Felizmente, há agora um forte interesse no impulso de colocar muito mais recursos em uma versão minimizada do Portal que se concentra no armazenamento distribuído e na acessibilidade da história. Esse ímpeto deve ser aproveitado, e devemos fazer um esforço concertado para implementar o EIP-4444 em breve, em conjunto com uma rede robusta descentralizada peer-to-peer para armazenar e recuperar a antiga história.

Para estados e ZK-EVMs, esse tipo de abordagem distribuída é mais difícil. Para construir um bloco eficiente, você simplesmente precisa ter o estado completo. Neste caso, eu pessoalmente prefiro uma abordagem pragmática: definimos e nos apegamos a algum nível de requisitos de hardware necessários para ter um 'nó que faça tudo', que seja maior do que o custo (idealmente em constante diminuição) de simplesmente validar a cadeia, mas ainda baixo o suficiente para ser acessível a entusiastas. Contamos com uma suposição de 1-de-N, onde garantimos que o N seja bastante grande. Por exemplo, isso poderia ser um laptop de consumo de alta qualidade.

A prova ZK-EVM provavelmente será a parte mais complicada, e os provadores ZK-EVM em tempo real provavelmente exigirão hardware consideravelmente mais robusto do que um nó de arquivo, mesmo comavanços como Binius, e pior caso limitado com,gás multidimensional. Poderíamos trabalhar arduamente em uma rede de provas distribuída, onde cada nó assume a responsabilidade de provar, por exemplo, um por cento da execução de um bloco, e então o produtor de bloco só precisa agregar as cem provas no final. Árvores de agregação de provas poderiam ajudar ainda mais. Mas se isso não funcionar bem, então um outro compromisso seria permitir que os requisitos de hardware da prova se tornem mais elevados, mas garantir que um “nó que faz tudo” possa verificar os blocos do Ethereum diretamente (sem uma prova), rápido o suficiente para participar efetivamente da rede.

Conclusões

Eu acho que é realmente verdade que o pensamento Ethereum da era de 2021 ficou muito confortável em transferir responsabilidades para um pequeno número de atores em grande escala, desde que algum tipo de mecanismo de mercado ou sistema de prova de conhecimento zero existisse para forçar os atores centralizados a se comportarem honestamente. Tais sistemas muitas vezes funcionam bem no caso médio, mas falham catastroficamente no pior caso.

Não estamos fazendo isso.

Ao mesmo tempo, acho importante enfatizar que as propostas atuais do protocolo Ethereum já se afastaram significativamente desse tipo de modelo e levam a sério a necessidade de uma rede verdadeiramente descentralizada. Ideias em torno de nós sem estado, mitigação de MEV, finalidade de slot único e conceitos semelhantes já estão muito mais nessa direção. Há um ano, a ideia de fazer amostragem de disponibilidade de dados se aproveitando de retransmissões como nós semidecentralizados foi seriamente considerada. Este ano, avançamos além da necessidade de fazer tais coisas, com progressos surpreendentemente robustos emPeerDAS.

Mas há muito que poderíamos fazer para avançar nessa direção, em todos os três eixos que mencionei acima, bem como em muitos outros eixos importantes.Heliosfez grandes progressos ao dar ao Ethereum um “cliente leve” real. Agora, precisamos incluí-lo por padrão nas carteiras do Ethereum e fazer com que os provedores de RPC forneçam provas juntamente com seus resultados para que possam ser validados e estender a tecnologia do cliente leve para protocolos de camada 2. Se o Ethereum está escalando por meio de um roadmap centrado em rollup, os protocolos de camada 2 precisam obter as mesmas garantias de segurança e descentralização que a camada 1. Em um mundo centrado em rollup, há muitas outras coisas que devemos levar mais a sério; pontes descentralizadas e eficientes entre L2s são apenas um exemplo de muitos. Muitos dapps obtêm seus logs por meio de protocolos centralizados, já que a verificação de logs nativa do Ethereum se tornou muito lenta. Poderíamos melhorar isso com um subprotocolo descentralizado dedicado;@vbuterin/parallel_post_state_roots">aqui está uma proposta minha de como isso poderia ser feito.

Há um número quase ilimitado de projetos de blockchain visando o nicho de "podemos ser super-rápidos, pensaremos na descentralização depois". Eu não acho que o Ethereum deva ser um desses projetos. O Ethereum L1 pode e certamente deve ser uma base forte para projetos de camada 2 que adotam uma abordagem de hiperescala, usando o Ethereum como espinha dorsal para descentralização e segurança. Mesmo uma abordagem centrada na camada 2 requer que a camada 1 em si tenha escalabilidade suficiente para lidar com um número significativo de operações. Mas devemos ter profundo respeito pelas propriedades que tornam o Ethereum único e continuar a trabalhar para manter e melhorar essas propriedades à medida que o Ethereum escala.

Aviso Legal：

1. Este artigo é reimpresso de [[Vitalik Buterin]], Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar 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, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.