Estou sentado aqui a escrever isto no último dia de uma interoperação de desenvolvedores 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, principalmentePeerDAS, o Transição de árvore Verklee abordagens descentralizadas para armazenar histórico no contexto deEIP 4444Na minha perspetiva, parece que o ritmo de desenvolvimento do Ethereum, e a nossa capacidade de lançar funcionalidades grandes e importantes que melhoram significativamente a experiência dos operadores de nós e dos utilizadores (L1 e L2), estão a aumentar.

Equipas de clientes Ethereum a trabalhar juntas para lançar a rede de desenvolvimento Pectra.

Dada esta maior capacidade técnica, uma questão importante a colocar é: estamos a construir em direção aos objetivos certos? Uma sugestão para refletir sobre isto é uma recente série de tweets infelizes do desenvolvedor principal de longa data do Geth, Peter Szilagyi:

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

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

MEV e dependência do construtor

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

Este era um sistema muito simples e favorável à descentralização: como mineiro, você pode simplesmente executar o software padrão e obter os mesmos níveis de receita de taxas de um bloco que 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 extraível pelo mineiro (MEV): receitas que só podiam ser obtidas executando estratégias complexas que estão cientes das atividades que acontecem 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 - em trocas centralizadas e em Uniswap - seja $3000. No momento T+11, a taxa de câmbio USD/ETH em trocas centralizadas sobe para $3005. Mas o Ethereum ainda não teve seu próximo bloco. No momento T+12, ele ocorre. 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. Isso é receita extra e é chamado de MEV. Aplicações que não sejam DEXes têm seus próprios análogos a este problema. Papel Flash Boys 2.0publicado em 2019 aborda este assunto em detalhe.

Um gráfico do papel 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 blocos) pode ser “justa”: agora, grandes atores que têm melhor capacidade de otimizar esses tipos de algoritmos de extração podem obter um retorno melhor por bloco.

Desde então, tem havido um debate entre duas estratégias, que eu chamarei de minimização de MEV e quarentena de MEV. A minimização de MEV vem em duas formas: (i) trabalhar agressivamente em alternativas livres de MEV para Uniswap (por exemplo. Cowswap) e (ii) desenvolver 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 podem capturar. Em particular, mempools criptografados impedem estratégias como ataques sandwich, que colocam transações imediatamente antes e depois das negociações dos usuários para explorá-los financeiramente ("front-running").

A quarentena de MEV funciona ao aceitar MEV, mas tentando limitar seu impacto na centralização do staking ao separar o mercado em dois tipos de agentes: os validadores são responsáveis por atestar e propor blocos, mas a tarefa de escolher os conteúdos do bloco é terceirizada para construtores especializados por meio de um protocolo de leilão. Os stakers individuais agora não precisam mais se preocupar em otimizar a arbitragem de defi; eles simplesmente participam do protocolo de leilão e aceitam a oferta mais alta. Isso é chamado de separação de proponente/construtor (PBS). Esta abordagem tem precedentes em outras indústrias: uma das principais razões pelas quais os restaurantes conseguem permanecer tão descentralizados é que muitas vezes dependem de um conjunto bastante concentrado de fornecedores para várias operações que têm grandes economias de escala. 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, isso cria outro problema: a tarefa de escolher quais transações serão incluídas se torna mais concentrada.

A minha opinião sobre isto tem sido sempre que a minimização do MEV é boa e que devemos persegui-la (eu pessoalmente uso regularmente o Cowswap!) - embora as mempools encriptadas tenham muitos desafios, a minimização do MEV provavelmente será insuficiente; o MEV não irá diminuir para zero, ou mesmo próximo de zero. Portanto, precisamos de algum tipo de quarentena do MEV também. Isto cria uma tarefa interessante: como podemos tornar a “caixa de quarentena do MEV” o mais pequena possível? Como podemos dar aos construtores o mínimo de poder possível, enquanto ainda os mantemos capazes de absorver o papel de otimizar a arbitragem e outras formas de recolha de MEV?

Se os construtores tiverem o poder de excluir transações de um bloco inteiramente, podem surgir ataques com bastante facilidade. Suponha que você tenha um posição de dívida colateralizada (CDP)num protocolo defi, apoiado por um ativo cujo preço está a cair rapidamente. Deseja aumentar a sua garantia ou sair do CDP. Os construtores maliciosos poderiam tentar coludir para recusar a inclusão da sua transação, atrasando-a até que os preços desçam o suficiente para poderem liquidar à força o seu CDP. Se isso acontecer, teria de pagar uma multa elevada e os construtores receberiam uma grande parte dela. Então, como podemos impedir que os construtores excluam transações e realizem este tipo de ataques?

Aqui é onde entram as listas de inclusão.

Origem: esta publicação ethresear.ch.

As listas de inclusão permitem que os proponentes de bloco (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 suas 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 acima foi um profundo buraco de coelho de antecedentes complicados. Mas o 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 o MEV, mas o MEV está à procura de você". Os pesquisadores de Ethereum já estão bastante alinhados com o objetivo de "minimizar a caixa de quarentena", reduzindo o dano que os construtores podem fazer (por exemplo, excluindo ou atrasando transações como forma de atacar aplicações específicas) o máximo possível.

Dito isto, acredito que podemos ir ainda mais longe. Historicamente, as listas de inclusão muitas vezes foram concebidas como uma característica especial "lado a lado": normalmente, não pensaria nelas, mas apenas no caso de construtores maliciosos começarem a fazer coisas loucas, elas oferecem-lhe um "segundo caminho". Esta atitude reflete-se nas decisões de design atuais: na 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 na forma como pensamos sobre as 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 os construtores tiverem o limite de gás de 2,1 milhões?

Penso que as ideias nesta direção - realmente empurrar a caixa de quarentena para ser o mais pequena possível - são realmente interessantes, e estou a favor de seguir nessa direção. Isto é uma mudança da filosofia da "era de 2021": na filosofia da era de 2021, estávamos mais entusiasmados com a ideia de que, agora que temos construtores, podemos "sobrecarregar" a sua funcionalidade e fazê-los servir os utilizadores de formas mais complicadas, por exemplo, ao apoiar Mercados de taxas ERC-4337. Nesta nova filosofia, as partes de validação de transações do ERC-4337 teriam de ser consagradas no protocolo. Felizmente, a equipa ERC-4337 já está @yoavCada vez mais entusiasmado com esta direção.

Resumo: A ideia de MEV já está a voltar na direção de capacitar os produtores de blocos, incluindo dar-lhes a autoridade para garantir diretamente a inclusão das transações dos utilizadores. As propostas de abstração de contas já estão a voltar na direção de remover a dependência de relayers centralizados e até mesmo de agrupadores. No entanto, há um bom argumento de que não estamos a ir longe o suficiente, e penso que a pressão que empurra o processo de desenvolvimento a avançar nessa direção é muito bem-vinda.

Staking líquido

Atualmente, os stakers individuais representam uma percentagem relativamente pequena de todo o staking do Ethereum, e a maioria do staking é feito por vários fornecedores - alguns operadores centralizados e outros DAOs, como Lido e RocketPool.

Eu fiz minha própria pesquisa - várias pesquisas[1] [2], pesquisas, conversas pessoais, fazendo a pergunta “por que você - especificamente você - não está participando do solo staking hoje?” Para mim, um ecossistema robusto de solo staking é 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 solo staking em vez de simplesmente nos rendermos à delegação. No entanto, estamos longe desse resultado. Nas minhas enquetes e pesquisas, existem algumas tendências consistentes:

1. A grande maioria das pessoas que não estão a estacar a solo citam como principal razão o mínimo de 32 ETH.
2. Dos que citam outras razões, o mais alto é 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 nos protocolos de defi são preocupações significativas, mas de menor dimensão.

As principais razões pelas quais as pessoas não estão a fazer staking a solo, de acordo com as sondagens da Farcaster.

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

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

Muitos dos itens em curso de investigação e desenvolvimento têm como objetivo resolver precisamente estes problemas:

1. Árvores VerklemaisEIP-4444permitir que os nós de staking funcionem com requisitos de disco rígido muito baixos. Além disso, permitem que os nós de staking sincronizem quase instantaneamente, simplificando grandemente o processo de configuração, bem como operações como a mudança de uma implementação para outra. Também tornam os clientes leves do Ethereum muito mais viáveis, reduzindo a largura de banda necessária para fornecer provas para cada acesso de estado.
2. Investigação (por exemplo, estas propostas)em maneiras de permitir um conjunto de validadores muito maior (permitindo mínimos de aposta muito menores) ao mesmo tempo que reduz a sobrecarga do nó de consenso. Estas ideias podem ser implementadas como parte de finalidade de slot único. Fazer isto também tornaria os clientes leves mais seguros, pois seriam capazes de verificar o conjunto completo de assinaturas em vez de dependerem de comissões de sincronização).
3. As otimizações contínuas do cliente Ethereum continuam a reduzir o custo e a dificuldade de executar um nó validador, apesar do crescimento da história.
4. Pesquisa sobre limitação de penalidadespoderia potencialmente mitigar preocupações em torno do risco da chave privada e permitir que os stakers apostem simultaneamente sua ETH em protocolos defi se assim o desejarem.
5. 0x01 Credenciais de levantamentopermitir que os stakers definam um endereço ETH como seu endereço de levantamento. Isso torna as pools de staking descentralizadas mais viáveis, dando-lhes uma 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 a cada vez que finaliza (ou seja, uma vez por época). Portanto, poderíamos reduzir muito mais o período de retirada se nos esforçássemos. Se quiséssemos reduzir drasticamente o tamanho do depósito mínimo, poderíamos tomar uma decisão difícil de compensação em outras direções, por exemplo, se aumentássemos o tempo de finalização em 4x, isso permitiria um @VitalikButerin/parametrizando-casper-a-troca-de-descida-do-tamanho-do-depósito-mínimo-4x. A finalidade de um único slot mais tarde limparia isso, movendo-se além do modelo 'cada validador participa em cada época' inteiramente.

Outra parte importante desta questão é a economia do staking. Uma questão chave é: queremos que o staking seja uma atividade relativamente de nicho, ou queremos que todos ou quase todos apostem todo o seu ETH? Se todos estiverem a apostar, qual é a responsabilidade que queremos que todos assumam? Se as pessoas acabarem simplesmente por delegar esta responsabilidade porque são preguiçosas, 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 passos 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 tocam no cerne da economia e valores do Ethereum, e por isso 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 por se resumir a uma questão que definiu a política blockchainpor uma década: quão acessível queremos tornar a execução de um nó e como?

Hoje em dia, executar um nó é difícil. A maioria das pessoas não o faz. No laptop que estou a usar para escrever este post, tenho um rethnó, e ocupa 2,1 terabytes - já o resultado de heroica engenharia de software e otimização. Precisei comprar um disco rígido extra de 4 TB para colocar no meu laptop a fim de armazenar este nó. Todos queremos que executar um nó seja mais fácil. No meu mundo ideal, as pessoas seriam capazes de 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 ambas forem implementadas, os requisitos de hardware de um nó poderiam eventualmente diminuir plausivelmente 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 staking).Tipo 1 ZK-EVMsremoveria a necessidade de executar a computação do EVM por si próprio, pois 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ó incorporado que verifica essas provas, faz amostragem de disponibilidade de dados e está satisfeito de que a cadeia está correta.

A visão descrita acima é frequentemente chamada de 'The Verge'.

Tudo isso é conhecido e compreendido, até pelas pessoas que levantam preocupações sobre o tamanho do nó 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 ainda não vai contra os princípios do Ethereum ao ficarmos muito dependentes deles?

Uma versão muito próxima a curto prazo desta preocupação é 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 atores grandes o suficiente (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.

Entretanto, este argumento baseia-se na dependência de um pequeno número de grandes atores. Em minhataxonomia 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 emEIP-4844-style blobs, 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 execução e de farol nos blobs.Fonte da imagem: codex.storage

Por muito tempo, este trabalho tem estado em segundo plano; Portal Networkexiste, mas realisticamente não tem recebido o nível de atenção condizente com a sua importância no futuro do Ethereum. Felizmente, há agora um forte interesse e momentum para direcionar muito mais recursos para uma versão minimizada do Portal que se concentra no armazenamento distribuído e acessibilidade da história. Este momentum deve ser aproveitado, e devemos fazer um esforço concertado para implementar o EIP-4444 em breve, em conjunto com uma rede robusta e descentralizada de pares para armazenar e recuperar a história antiga.

Para os estados e ZK-EVMs, este tipo de abordagem distribuída é mais difícil. Para construir um bloco eficiente, simplesmente tem de ter o estado completo. Neste caso, pessoalmente prefiro uma abordagem pragmática: definimos e aderimos a algum nível de requisitos de hardware necessários para ter um “nó que faz tudo”, que é superior ao custo (idealmente decrescente) 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 é bastante grande. Por exemplo, isto poderia ser um portátil de consumo de alta qualidade.

Provar ZK-EVM provavelmente será a parte mais complicada, e os provadores em tempo real de ZK-EVM provavelmente exigirão hardware consideravelmente mais robusto do que um nó de arquivo, mesmo com avanços como Binius, e pior caso de limitação comgás multidimensional. Poderíamos trabalhar arduamente numa 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 depois o produtor de blocos só precisa agregar as cem provas no final. As á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 para a prova se tornassem mais elevados, mas garantir que um 'nó que faz tudo' possa verificar os blocos de Ethereum diretamente (sem uma prova), rápido o suficiente para participar efetivamente na rede.

Conclusões

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

Não estamos a fazer isto.

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. As ideias em torno de nós sem estado, mitigação de MEV, finalidade de slot único e conceitos similares já estão muito mais nessa direção. Há um ano, a ideia de realizar amostragem de disponibilidade de dados por meio de retransmissões como nós semicentralizados foi seriamente considerada. Este ano, avançamos além da necessidade de fazer tais coisas, com um progresso surpreendentemente robusto emPeerDAS.

Mas há muito que podemos fazer para avançar ainda mais nesta direção, em todos os três eixos de que falei acima, bem como em muitos outros eixos importantes.Heliosfez grandes progressos ao dar ao Ethereum um "cliente leve" real. Agora, precisamos que ele seja incluído por padrão nas carteiras Ethereum e fazer com que os provedores RPC forneçam provas juntamente com seus resultados para que possam ser validados e estender a tecnologia de 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 ter as mesmas garantias de segurança e descentralização que a camada 1. Em um mundo centrado em rollup, existem muitas outras coisas que devemos levar mais a sério; pontes cruzadas descentralizadas e eficientes entre L2 são um exemplo entre muitos. Muitos dapps obtêm seus logs por meio de protocolos centralizados, já que a varredura 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 sobre como isso poderia ser feito.

Há um número quase ilimitado de projetos de blockchain que visam o nicho de "podemos ser super rápidos, pensaremos na descentralização mais tarde". Não acredito que o Ethereum deva ser um desses projetos. O Ethereum L1 pode e certamente deve ser uma base sólida para projetos de camada 2 que adotem uma abordagem hiper-escalável, usando o Ethereum como uma espinha dorsal para a descentralização e segurança. Mesmo uma abordagem centrada na camada 2 requer que a camada 1 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 se expande.

Aviso legal：

1. Este artigo é reproduzido 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 oGate Learnequipa 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 equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.