Autor: Vitalik Compilador: Deng Tong, Golden Finance;
Agradecimentos especiais a Dankrad Feist, Caspar Schwarz-Schilling e Francesco pelo rápido feedback e revisão.
Enquanto estou aqui sentado escrevendo isto no último dia do Ethereum Developer Interop no Quênia, fizemos um grande progresso na implementação e no aperfeiçoamento dos detalhes técnicos de importantes melhorias futuras do Ethereum, mais notavelmente PeerDAS, transição de árvore Verkle e métodos descentralizados para armazenar histórico no contexto do EIP 4444. Do meu ponto de vista, o ritmo de desenvolvimento do Ethereum e nossa capacidade de fornecer recursos grandes e importantes que melhoram significativamente a experiência para operadores de nós e usuários (L1 e L2) estão aumentando constantemente.
A equipe do cliente Ethereum trabalha em conjunto para entregar a rede de desenvolvimento Pectra.
À luz do aumento das capacidades tecnológicas, uma questão importante a colocar é: estamos a avançar em direcção aos objectivos certos? Uma série recente de tweets descontentes do antigo desenvolvedor principal do Geth, Peter Szilagyi, nos fez pensar sobre isso:
Essas preocupações são válidas. Esta é uma preocupação expressada por muitos na comunidade Ethereum. Eu pessoalmente me preocupei com essas questões muitas vezes. No entanto, também não acho que a situação seja tão desesperadora quanto sugere o tweet de Peter. Em vez disso, muitos problemas já estão sendo resolvidos por meio de recursos de protocolo contínuos, enquanto muitos outros poderiam ser resolvidos com ajustes muito reais no roteiro atual.
Para entender o que isso significa na prática, vamos rever os três exemplos fornecidos por Pedro, um por um. Estas questões são preocupações comuns entre muitos membros da comunidade e é importante abordá-las.
Dependências de MEV e construtor
No passado, os blocos Ethereum eram criados por mineradores, que usavam algoritmos relativamente simples para criar blocos. Os usuários enviam transações para uma rede p2p pública, geralmente chamada de “mempool” (ou “txpool”). Os mineiros ouvem o mempool, aceitam transações válidas e pagam taxas. Incluem transações que podem ser realizadas e, caso não haja espaço suficiente, são priorizadas na ordem de maior tarifa.
É um sistema muito simples e fácil de descentralização: como minerador, basta executar o software padrão e obter o mesmo nível de receita de taxas de um bloco que obteria de uma fazenda de mineração altamente profissional. No entanto, por volta de 2020, as pessoas começaram a tirar partido do chamado valor extraível do mineiro (MEV): receitas que só podem ser obtidas através da execução de estratégias complexas que compreendem as atividades que ocorrem dentro de vários protocolos defi.
Por exemplo, considere uma exchange descentralizada como o Uniswap. Suponha que no momento T, a taxa de câmbio USD/ETH nas exchanges centralizadas e no Uniswap seja de US$ 3.000. Em T+11, a taxa de câmbio USD/ETH na bolsa centralizada subiu para US$ 3.005. Mas o Ethereum ainda não tem o próximo bloco. No momento T+12, este é realmente o caso. Quem quer que tenha criado o bloco, sua primeira transação poderia ser uma série de compras no Uniswap para comprar todo o ETH disponível no Uniswap por entre US$ 3.000 e US$ 3.004. Esta é uma renda adicional, chamada MEV. Outros aplicativos além do DEX apresentam problemas semelhantes. O artigo Flash Boys 2.0 publicado em 2019 detalha isso em detalhes.
O gráfico no artigo Flash Boys 2.0 mostra a quantidade de receita que pode ser obtida usando cada um dos métodos acima.
O problema é que isso explica a razão pela qual a mineração (ou propostas de blocos após 2022) pode ser “justa”: agora, grandes players com melhores capacidades para otimizar tais algoritmos de extração podem obter mais retornos bons em cada bloco.
Desde então, tem havido um debate contínuo entre duas estratégias, que chamo de minimização do MEV e isolamento do MEV. A minimização de MEV ocorre de duas formas: (i) desenvolvimento ativo de alternativas livres de MEV para Uniswap (por exemplo, Cowswap), e (ii) construção de tecnologia em protocolo, como pools de memória criptográfica que reduzem as informações disponíveis para os produtores de blocos, reduzindo assim sua renda que pode ser obtido. Em particular, os mempools criptografados protegem contra estratégias como ataques sanduíche, que colocam as transações antes e depois das transações do usuário para explorá-las financeiramente ("front-running").
A segregação de MEV funciona aceitando MEV, mas tentando limitar seu impacto na centralização de staking, dividindo o mercado em dois tipos de participantes: os validadores são responsáveis por provar e propor blocos, mas a tarefa de selecionar o conteúdo do bloco é através de um protocolo de leilão. Os stakers individuais agora não precisam mais se preocupar em otimizar a arbitragem DeFi; eles simplesmente aderem ao protocolo de leilão e aceitam o lance mais alto. Isso é chamado de Separação Proponente/Construtor (PBS). Esta abordagem tem precedentes noutras indústrias: uma das principais razões pelas quais os restaurantes conseguiram permanecer tão fragmentados é que tendem a depender de um conjunto bastante centralizado de fornecedores para as suas diversas operações, que apresentam enormes economias de escala. Até agora, a PBS tem tido bastante sucesso em garantir que os pequenos e grandes validadores estejam em condições de igualdade, pelo menos no que diz respeito ao MEV. Contudo, cria outro problema: a tarefa de escolher quais transações incluir torna-se mais centralizada.
Minha opinião sobre isso sempre foi que a minimização do MEV é boa e devemos persegui-la (eu pessoalmente uso muito o Cowswap!) - embora haja muitos desafios com mempools criptografados, a minimização do MEV pode não ser suficiente; até perto de zero. Portanto, também precisamos de algum tipo de isolamento MEV. Isto deu origem a uma tarefa interessante: Como tornar a “caixa de isolamento MEV” o menor possível? Como damos aos construtores o mínimo de poder possível e, ao mesmo tempo, permitimos que eles absorvam os efeitos da arbitragem de otimização e outras formas de coleta de MEV?
Se o construtor tiver o poder de excluir totalmente as transações do bloco, os ataques poderão ocorrer facilmente. Digamos que você tenha uma posição de dívida garantida (CDP) em um protocolo defi, respaldada por um ativo cujo preço está caindo rapidamente. Você deseja adicionar garantia ou sair do CDP. Construtores maliciosos podem tentar conspirar para rejeitar negociações que incluam você, atrasando as negociações até que o preço caia o suficiente para forçar a liquidação do seu CDP. Se isso acontecer, você terá que pagar uma multa pesada e a construtora receberá uma grande parcela. Então, como podemos evitar que os construtores excluam transações e concluam esse tipo de ataque?
É aqui que entram as listas incluídas.
Fonte: postagens ethresear.ch.
A lista de inclusão permite que os proponentes do bloco (ou seja, as partes interessadas) selecionem as transações necessárias para entrar no bloco. Os construtores ainda podem reordenar transações ou inserir suas próprias transações, mas devem incluir as transações do proponente. Finalmente, a lista de inclusão foi modificada para restringir o próximo bloco em vez do bloco atual. Em ambos os casos, eles eliminam a capacidade do construtor de empurrar as transações completamente para fora do bloco.
MEV é um problema complexo; mesmo a descrição acima perde muitas nuances importantes. Como disse: “Você pode não estar procurando o MEV, mas o MEV está procurando por você”. Os pesquisadores da Ethereum têm sido muito consistentes em trabalhar em direção ao objetivo de “contenção mínima”, minimizando os danos que os construtores podem causar (por exemplo, excluindo ou atrasando transações como forma de atacar uma aplicação específica).
Dito isto, penso que podemos ir mais longe. Historicamente, as listas de inclusão têm sido consideradas um "recurso de caso especial": normalmente, você não pensa nelas, mas caso um construtor malicioso comece a fazer coisas malucas, elas lhe dão um "segundo caminho". decisões de design: no EIP atual, o limite de gás das listas de inclusão é de cerca de 2,1 milhões. Mas podemos fazer uma mudança filosófica na forma como pensamos nas listas de inclusão: pense nas listas de inclusão como blocos auxiliares. função para adicionar algumas transações para coletar MEV. E se o construtor tiver um limite de 2,1 milhões de gás?
Acho que a ideia dessa direção - realmente pressionar para que a caixa de isolamento seja a menor possível - é muito interessante e sou a favor de ir nessa direção. Esta é uma mudança da “filosofia 2021”: Na filosofia 2021, estamos mais entusiasmados com a ideia de que, como agora temos construtores, podemos “sobrecarregar” a sua funcionalidade e deixá-los servir de formas mais complexas, serviços ao utilizador, por exemplo. . Apoiando o mercado de taxas ERC-4337. Nesta nova filosofia, a parte de verificação de transações do ERC-4337 deve ser incorporada ao protocolo. Felizmente, a equipe do ERC-4337 tem ficado cada vez mais entusiasmada nessa direção.
Resumo: O pensamento MEV voltou ao sentido de capacitar os produtores de blocos, incluindo dar aos produtores de blocos o poder de garantir diretamente a inclusão das transações dos usuários. As propostas de abstração de contas voltaram no sentido de eliminar a dependência de retransmissores centralizados ou mesmo de empacotadores. No entanto, há um bom argumento de que não fomos suficientemente longe e penso que a pressão para impulsionar o processo de desenvolvimento nesta direcção é muito bem-vinda.
Estacamento de Liquidez
Hoje, os stakers individuais representam uma porcentagem relativamente pequena de todo o staking do Ethereum, e a maior parte do staking é feita por uma variedade de provedores – alguns operadores centralizados e outros DAOs como Lido e RocketPool.
Eu fiz minha própria pesquisa - várias enquetes, pesquisas, conversas cara a cara, fazendo a pergunta "Por que você - especialmente você - não aposta sozinho hoje? Para mim, até agora, um poderoso ecossistema de staking é meu?" O resultado preferido para apostar no Ethereum, e uma das melhores coisas sobre o Ethereum é que realmente tentamos apoiar um ecossistema de piquetagem forte e separado, em vez de apenas sucumbir à delegação. Porém, ainda estamos longe deste resultado. Em minhas enquetes e pesquisas, existem algumas tendências consistentes:
A grande maioria das pessoas que não apostam individualmente cita o mínimo de 32 ETH como principal motivo.
Dos que citaram outros motivos, o maior foi o desafio técnico de execução e manutenção de nós validadores.
A perda de disponibilidade instantânea de ETH, os riscos de segurança das chaves privadas “quentes” e a perda da capacidade de participar simultaneamente em protocolos DeFi são questões significativas, mas menores.
Uma pesquisa da Farcaster revelou os principais motivos pelos quais as pessoas não apostam individualmente.
A pesquisa de implantação precisa abordar duas questões principais:
Como abordamos essas preocupações?
Embora existam soluções válidas para a maioria dos problemas, se a maioria das pessoas ainda não quer apostar sozinha, como podemos manter o protocolo estável e robusto contra ataques, apesar disso?
Muitos projetos de pesquisa e desenvolvimento em andamento visam abordar precisamente estas questões:
As árvores Verkle juntamente com o EIP-4444 permitem que os nós de piquetagem sejam executados com requisitos de disco rígido muito baixos. Além disso, eles permitem que os nós de piquetagem sincronizem quase instantaneamente, simplificando muito coisas como configuração e mudança de uma implementação para outra. Eles também tornam os clientes leves do Ethereum mais viáveis, reduzindo a largura de banda de dados necessária para fornecer provas para o acesso de cada estado.
Investigue métodos (como essas propostas) para permitir conjuntos maiores de validadores (permitindo mínimos de piquetagem menores) e, ao mesmo tempo, reduzindo a sobrecarga do nó de consenso. Essas ideias podem ser implementadas como parte da finalidade de slot único. Isso também tornará os clientes light mais seguros, pois poderão verificar o conjunto completo de assinaturas em vez de depender de comitês de sincronização).
Apesar de sua história crescente, as otimizações contínuas do cliente Ethereum continuam a reduzir o custo e a dificuldade de executar um nó validador.
A pesquisa sobre limites de penalidade pode aliviar as preocupações sobre o risco de chave privada e permitir que os stakeholders apostem simultaneamente seus ETH em protocolos DeFi, se assim o desejarem.
0x01 O certificado de retirada permite que o staker defina o endereço ETH como endereço de retirada. Isso torna os pools de piquetagem descentralizados mais viáveis, dando-lhes uma vantagem sobre os pools de piquetagem centralizados.
No entanto, ainda podemos fazer mais. Teoricamente, os validadores podem retirar-se mais rapidamente: mesmo que o conjunto de validadores mude alguns pontos percentuais cada vez que for finalizado (ou seja, uma vez por época), Casper FFG ainda estará seguro. Portanto, se trabalharmos arduamente, poderemos encurtar significativamente o ciclo. Se quiséssemos reduzir significativamente o tamanho mínimo do depósito, poderíamos tomar a difícil decisão de negociar em outras direções. Por exemplo, se aumentarmos o tempo de finalização em 4x, o tamanho mínimo do depósito diminuirá em 4x. A finalidade de slot único resolverá mais tarde esse problema, indo além do modelo “cada staker participa em cada época”.
Outra parte importante de toda esta questão é a economia do staking. Uma questão chave é: Queremos que o staking se torne uma atividade relativamente de nicho, ou queremos que todos, ou quase todos, façam o staking de toda a sua ETH? Se todos estão apostando, que responsabilidade queremos que todos tenham? Se as pessoas acabarem simplesmente delegando responsabilidades por preguiça, isso poderá levar à centralização. Há questões filosóficas importantes e profundas aqui. A resposta errada poderia levar a Ethereum ao caminho da centralização e “recriar o sistema financeiro tradicional com etapas adicionais”; a resposta certa poderia criar um exemplo brilhante de um ecossistema de sucesso com uma ampla e diversificada parte interessada independente e um pool de staking altamente descentralizado; Estas questões envolvem a economia e os valores centrais do Ethereum, por isso precisamos de uma participação mais diversificada.
Requisitos de hardware do nó
Muitas das principais questões em torno da descentralização do Ethereum resumem-se, em última análise, a uma questão que definiu uma década de blockchain: com que facilidade queremos executar nós e como fazemos isso acontecer?
Executar um nó é difícil hoje em dia. A maioria das pessoas não faz isso. No laptop que estou usando para escrever este artigo, tenho um nó reth que ocupa 2,1 TB - já o resultado de uma heroica engenharia e otimização de software. Preciso comprar um disco rígido adicional de 4 TB para colocar em meu laptop e armazenar o nó. Todos nós queremos facilitar a execução de nós. No meu mundo ideal, as pessoas seriam capazes de executar nós em seus telefones.
Como escrevi acima, as árvores EIP-4444 e Verkle são duas tecnologias-chave que nos aproximam desse ideal. Se ambos forem implementados, os requisitos de hardware do nó poderão eventualmente ser reduzidos para menos de cem gigabytes, ou mais próximos de zero se removermos completamente a responsabilidade de armazenamento do histórico (provavelmente apenas para nós sem piquetagem). O ZK-EVM tipo 1 eliminará a necessidade de executar você mesmo os cálculos do EVM, pois você pode simplesmente verificar a prova de que a execução foi correta. No meu mundo ideal, empilhamos todas essas tecnologias juntas, e até mesmo as carteiras de extensão do navegador Ethereum (por exemplo, Metamask, Rabby) têm um nó integrado para verificar essas provas, fazer amostragem de disponibilidade de dados e garantir que a cadeia esteja correta.
Esta visão é muitas vezes referida como "The Verge".
Tudo isso é bem conhecido e compreendido, mesmo por aqueles que levantaram preocupações sobre o tamanho do nó Ethereum. Porém, há uma preocupação importante: se retirarmos a responsabilidade de manter o estado e fornecer provas, não será este um vetor centralizado? Mesmo que eles não possam trapacear fornecendo dados inválidos, confiar demais neles não vai contra os princípios do Ethereum?
Uma versão mais recente dessa preocupação é o desconforto que muitos sentem com o EIP-4444: se os nós regulares do Ethereum não precisam mais armazenar histórico antigo, quem precisa? Uma resposta comum é: deve haver grandes players suficientes (por exemplo, exploradores de blocos, exchanges, Camada 2) com um incentivo para manter esses dados, e a cadeia Ethereum é pequena em comparação com os 100 petabytes armazenados pela Wayback Machine. Portanto, a ideia de que qualquer história seria realmente perdida é absurda.
No entanto, este argumento baseia-se num pequeno número de grandes intervenientes. Na minha classificação de modelos de confiança, esta é uma suposição de 1 em N, mas N é muito pequeno. Isso tem seus riscos finais. Uma coisa que podemos fazer é armazenar o histórico antigo em uma rede ponto a ponto, onde cada nó armazena apenas uma pequena parte dos dados. Essa rede ainda seria replicada o suficiente para garantir robustez: haveria milhares de cópias de cada dado e, no futuro, poderíamos usar codificação de eliminação (na verdade, colocando o histórico em blobs no estilo EIP-4844, isso tem codificação de eliminação incorporada) para melhorar ainda mais a estabilidade.
Os blobs possuem codificação de eliminação dentro e entre os blobs. A maneira mais simples de fornecer armazenamento ultraestável para toda a história do Ethereum é provavelmente colocar beacons e blocos de execução em blobs. Fonte da imagem: codex.storage
Este trabalho há muito ficou em segundo plano. A Rede de Portal existe, mas não recebe realmente o nível de atenção proporcional à sua importância para o futuro do Ethereum. Felizmente, agora há um impulso para colocar mais recursos em uma versão mínima do portal focada no armazenamento distribuído e na acessibilidade histórica. Devemos aproveitar isso e trabalhar juntos para implementar o EIP-4444 o mais rápido possível, emparelhado com uma forte rede ponto a ponto descentralizada para armazenar e recuperar histórico antigo.
Para stateful e ZK-EVM, esta abordagem distribuída é mais difícil. Para construir um bloco eficiente, você só precisa ter um estado completo. Neste caso, eu pessoalmente prefiro adotar uma abordagem pragmática: definimos e insistimos em algum nível de requisitos de hardware necessários para ter um “nó que faz tudo”, que é superior ao custo de um simples nó validador (de preferência constantemente reduzido). cadeia, mas ainda baixo o suficiente para os entusiastas pagarem. Contamos com a suposição de 1 em N, garantindo que N seja razoavelmente grande.
As provas ZK-EVM são provavelmente a parte mais complicada, os provadores ZK-EVM em tempo real provavelmente exigirão hardware mais poderoso do que nós de arquivo, mesmo com avanços como Binius e limites de pior caso em gás multidimensional. Poderíamos trabalhar em uma rede de provas distribuídas, onde cada nó assume a responsabilidade de provar, digamos: um por cento da execução de um bloco, e então o produtor do bloco só precisa agregar cem provas no final. Mostre que as árvores agregadas podem ajudar ainda mais. Mas se isso não funcionar bem, então outro compromisso seria permitir que os requisitos de hardware para provas se tornassem maiores, mas garantir que os “nós que fazem tudo” possam validar diretamente os blocos Ethereum (sem provas) com rapidez suficiente para serem eficientes. Participe da rede.
Resumir
Acho que o pensamento Ethereum na era de 2021 realmente se acostumou a transferir a responsabilidade para um pequeno número de grandes players, desde que haja algum tipo de mecanismo de mercado ou sistema à prova de conhecimento zero para forçar os atores centralizados a agir honestamente. Tais sistemas funcionam frequentemente bem em circunstâncias normais, mas podem falhar catastroficamente no pior cenário.
Ao mesmo tempo, acho importante enfatizar que as propostas atuais do protocolo Ethereum se afastaram significativamente desse modelo e levaram muito mais a sério a necessidade de uma rede verdadeiramente descentralizada. As ideias sobre nós sem estado, mitigação de MEV, finalidade de slot único e conceitos semelhantes foram mais longe nessa direção. Há um ano, a ideia de amostrar a disponibilidade de dados por meio de relés como nós semicentralizados foi seriamente considerada. Este ano, já não temos de fazer estas coisas e o PeerDAS registou um progresso surpreendentemente forte.
Mas há muito que podemos fazer para ir mais longe nesta direcção, nas três questões centrais que mencionei acima, e em muitas outras questões importantes. Helios fez grandes avanços no fornecimento de um “cliente verdadeiramente leve” para Ethereum. Agora precisamos incluí-lo por padrão nas carteiras Ethereum e fazer com que os provedores de RPC forneçam provas e seus resultados para que possam ser verificados e estender a tecnologia de cliente leve para protocolos de camada 2. Se o Ethereum for dimensionado através de um roteiro centrado no Rollup, a Camada 2 precisará obter as mesmas garantias de segurança e descentralização que a Camada 1. Há muitas outras coisas em um mundo centrado no Rollup que deveríamos levar mais a sério. As pontes cross-L2 descentralizadas e eficientes são um dos muitos exemplos; Muitos dapps obtêm seus logs por meio de protocolos centralizados porque a varredura de logs nativa do Ethereum se tornou muito lenta. Podemos melhorar isso com subprotocolos descentralizados dedicados. Aqui está uma das minhas sugestões sobre como fazer isso.
Há um número quase infinito de projetos de blockchain direcionados ao mercado “podemos ser super rápidos e pensaremos na descentralização mais tarde”. Não acho que Ethereum deveria aderir a esse movimento. O Ethereum L1 pode e certamente deve ser uma camada de base forte para projetos da camada 2 que adotam uma abordagem de hiperescala, usando o Ethereum como a espinha dorsal da descentralização e da segurança. Mesmo uma abordagem centrada na Camada 2 exige que a própria Camada 1 seja escalonável o suficiente para lidar com um grande número de operações. Mas devemos respeitar profundamente os recursos que tornam o Ethereum único e continuar a trabalhar para manter e melhorar esses recursos à medida que o Ethereum cresce.
