Autor: Vitalik, fundador do Ethereum; Compilado por: Deng Tong, Jinse Caijing
Nota: Este artigo é a terceira parte da série "Desenvolvimento Futuro do Protocolo Ethereum" publicada recentemente por Vitalik, o fundador do Ethereum, intitulada "Possíveis futuros do protocolo Ethereum, parte 3: A Praga". A segunda parte pode ser encontrada no Jinse Finance "Vitalik: Como o protocolo Ethereum deve evoluir na fase Surge", e a primeira parte pode ser vista em "Quais melhorias ainda podem ser feitas no PoS do Ethereum". Abaixo está o texto completo da terceira parte:
Ethereum L1 enfrenta um dos maiores riscos devido à centralização da prova de participação resultante de pressões econômicas. Se houver economias de escala na participação do mecanismo central de prova de participação, isso naturalmente levará a grandes partes interessadas a dominarem, enquanto as pequenas partes interessadas se retiram para se juntarem a grandes pools de mineração. Isso resulta em um maior risco de ataques de 51%, revisão de transações e outras crises. Além do risco de centralização, também existe o risco de extração de valor: uma pequena parte das pessoas obtém o valor que originalmente iria para os usuários do Ethereum.
No ano passado, nossa compreensão desses riscos aumentou significativamente. É bem conhecido que esse risco existe em dois locais-chave: (i) construção de blocos, e (ii) regulamentos de capital de staking. Participantes maiores podem executar algoritmos mais complexos (“extração MEV”) para gerar blocos, resultando em uma receita de bloco mais alta para eles. Participantes grandes também podem resolver de maneira mais eficaz a inconveniência do capital bloqueado, liberando fundos como tokens de staking líquidos (LST) para outros. Além dos problemas diretos entre pequenos e grandes stakers, também há a questão de se (ou se haverá) uma superabundância de staking de ETH.
Roteiro Scourge 2023
Este ano, a construção do blockchain fez progressos significativos, sendo o mais notável a fusão da "lista de inclusão do comitê juntamente com algumas soluções de ordenação direcionadas" como a solução ideal, bem como a importante pesquisa sobre a economia da prova de participação, incluindo modelos de staking de duas camadas e a redução da emissão para limitar a percentagem de ETH em staking.
Os principais objetivos da praga
Tentar minimizar os riscos de centralização do nível de staking do Ethereum (especialmente em relação à construção de blocos e fornecimento de capital, também conhecidos como MEV e pools de staking)
Tentar minimizar o risco de extrair valor excessivamente dos usuários.
Este artigo é dividido em três partes
Corrigindo o pipeline de construção de blocos
Corrigindo a economia de staking
Soluções de camada de aplicação (Application-layer solutions)
Reparar construção de blocos
Que problema queremos resolver?
Atualmente, a construção de blocos no Ethereum é realizada principalmente através da separação entre o propositor e o construtor fora do protocolo MEVBoost. Quando um validador tem a oportunidade de propor um bloco, ele delega a tarefa de escolher o conteúdo do bloco a participantes especializados chamados construtores. A tarefa de selecionar o conteúdo do bloco que maximiza a receita é intensiva em economias de escala: requer algoritmos especializados para determinar quais transações incluir, a fim de extrair o máximo valor possível das ferramentas financeiras na cadeia e das transações dos usuários que interagem com elas (o que é conhecido como "extração de MEV"). Os validadores enfrentam uma tarefa de "dumb-pipe" relativamente leve em termos de economias de escala, que consiste em ouvir os lances e aceitar o lance mais alto, além de outras responsabilidades como a prova.
Gráfico programático do que o MEVBoost está fazendo: construtores dedicados assumem as tarefas em vermelho, enquanto os stakeholders assumem as tarefas em azul.
Existem várias versões, incluindo "Separação de Proponentes e Construtores" (PBS) e "Separação de Proponentes e Validadores" (APS). A diferença entre elas está relacionada a detalhes mais finos, ou seja, quais responsabilidades são assumidas por qual dos dois participantes: de forma geral, no PBS, os validadores ainda propõem blocos, mas recebem a carga útil do construtor, enquanto no APS, toda a responsabilidade do slot recai sobre o construtor. Recentemente, o APS tem sido mais favorecido do que o PBS, pois reduz ainda mais o incentivo para os proponentes e construtores estarem juntos. Note que o APS se aplica apenas a blocos de execução que contêm transações; blocos de consenso que contêm dados relacionados à prova de participação (como provas) ainda serão aleatoriamente alocados aos validadores.
Essa separação de poderes ajuda a manter a descentralização dos validadores, mas tem um custo importante: os participantes que executam tarefas "especializadas" podem facilmente se tornar muito centralizados. Esta é a construção de blocos do Ethereum hoje:
Dois participantes estão escolhendo o conteúdo de cerca de 88% dos blocos do Ethereum. E se esses dois participantes decidirem revisar as transações? A resposta não é tão ruim quanto parece: eles não podem reestruturar os blocos, portanto, você não precisa de 51% de revisão para impedir que as transações sejam incluídas: você precisa de 100%. Com um mecanismo de revisão de 88%, os usuários em média precisam esperar 9 slots (tecnicamente, uma média de 114 segundos, em vez de 6 segundos). Para alguns casos de uso, esperar por certas transações por dois minutos ou até cinco minutos pode ser suficiente. Mas para outros casos de uso, como liquidações DeFi, mesmo a capacidade de atrasar a inclusão das transações de outras pessoas por alguns blocos representa um risco significativo de manipulação de mercado.
As estratégias que os construtores de blocos podem usar para maximizar a receita também podem ter outros efeitos negativos sobre os usuários. Um "ataque de sanduíche" pode causar perdas significativas aos usuários que realizam transações de tokens devido ao deslizamento. Para bloquear as transações introduzidas por esses ataques, os preços do Gas de outros usuários aumentaram.
O que é e como funciona?
A solução líder é dividir ainda mais a tarefa de produção de blocos: vamos devolver a tarefa de seleção de transações aos proponentes (ou seja, os stakers), enquanto os construtores só podem escolher a ordem e inserir algumas de suas próprias transações. É isso que a lista de inclusão quer fazer.
No tempo T, um validador selecionado aleatoriamente cria uma lista de inclusão, ou seja, uma lista de transações válidas com base no estado atual da blockchain. No tempo T+1, o construtor de bloco (que pode ter sido escolhido antecipadamente através de um mecanismo de leilão dentro do protocolo) cria um bloco. Este bloco precisa incluir cada transação da lista de inclusão, mas eles podem escolher a ordem e adicionar suas próprias transações.
A proposta da Lista de Inclusão de Forks Obrigatórios (FOCIL) envolve um comitê composto por vários criadores de listas de inclusão para cada bloco. Para atrasar uma transação em um bloco, k dos criadores de listas de inclusão, entre k (por exemplo, k = 16), devem revisar a transação. O FOCIL, combinado com o proponente final selecionado por leilão, deve incluir a lista de inclusão, mas pode ser reorganizado e novas transações podem ser adicionadas, geralmente chamadas de "FOCIL + APS".
Outra maneira de resolver o problema é através de múltiplos proponentes em paralelo (MCP), como o BRAID. O BRAID tenta evitar a divisão do papel de proponente de bloco em partes de baixa e alta economia de escala, mas tenta distribuir o processo de produção de blocos entre muitos participantes, de modo que cada proponente só precise ter um nível médio de complexidade para maximizar sua receita. O funcionamento do MCP é permitir que k proponentes paralelos gerem listas de transações e, em seguida, usem um algoritmo determinístico (por exemplo, ordenação por taxas, da mais alta para a mais baixa) para escolher a ordem.
BRAID não busca implementar a proposta de bloco dumb-pipe do software padrão como o melhor objetivo. Existem duas razões fáceis de entender pelas quais isso não pode ser feito:
Ataque de arbitragem tardio: Suponha que o tempo médio para o proponente se comprometer é T, e o tempo que você pode enviar pela última vez e ainda ser incluído é cerca de T+1. Agora, digamos que em uma bolsa centralizada, o preço ETH / USDC vai de $2500 a $2502 entre T e T+1. Os proponentes podem esperar um segundo extra e, em seguida, adicionar transações adicionais à arbitragem de exchanges descentralizadas on-chain, ganhando até US $ 2 em lucro por ETH. Proponentes experientes com boas conexões à rede estão mais bem equipados para fazer isso.
Fluxo de pedidos exclusivo: Os usuários têm motivação para enviar transações diretamente a um único proponente, a fim de minimizar sua vulnerabilidade a transações front-running e outros ataques. Proponentes experientes têm uma vantagem, pois podem estabelecer infraestrutura para aceitar essas transações diretamente dos usuários e possuem uma reputação mais forte, permitindo que os usuários que enviam transações confiem que o proponente não os trairá e fará front-running (o que pode ser mitigado com o uso de hardware confiável, mas o hardware confiável possui suas próprias suposições de confiança.)
No BRAID, o provador ainda pode ser separado e operar como uma função de tubo estúpido.
Além desses dois extremos, existe uma série de possíveis designs que se situam entre os dois. Por exemplo, você pode leiloar um papel que tenha apenas o direito de anexar a um bloco, sem o direito de reordenar ou preceder. Você pode até permitir que eles anexem ou precedam, mas não insiram no meio ou reordenem. O apelo dessas técnicas reside no fato de que os vencedores do mercado de leilões podem ser muito concentrados, portanto, reduzir sua autoridade traz muitos benefícios.
memória pool criptografia
Uma tecnologia que é crítica para a implementação bem-sucedida de muitos desses projetos (especificamente, versões BRAID ou APS, que têm restrições rígidas na funcionalidade de leilão) são os mempools criptografados. Um mempool de criptografia é uma técnica na qual um usuário transmite sua transação de forma criptografada com algum tipo de prova de validade, e a transação está contida em um bloco em forma criptografada sem que o construtor de blocos conheça seu conteúdo. Os detalhes da transação serão anunciados posteriormente.
O principal desafio de implementar um pool de memória criptografada é propor um design que assegure que todas as transações serão divulgadas mais tarde: um simples esquema de "submissão e divulgação" não funciona, pois se a divulgação é voluntária, a própria escolha de divulgar ou não divulgar tem um efeito de "último impulsionador" sobre os blocos que podem ser explorados. As duas técnicas principais são (i) decriptação por limiar e (ii) criptografia atrasada, que é um primitivo intimamente relacionado à função de atraso verificável (VDF).
Quais as ligações com a pesquisa existente?
Explicação sobre a centralização de MEV e construtores:
MEVBoost：
PBS consagrado (soluções propostas precocemente para esses problemas):
Lista de leituras relacionadas à lista de inclusão de Mike Neuder:
Lista de EIPs incluídos:
FOCIL：
Demonstração BRAID de Max Resnick:
“A prioridade é o que você precisa”, autor: Dan Robinson:
Sobre ferramentas e protocolos de múltiplos proponentes:
VDFResearch.org：
Funções de atraso verificáveis e ataques (com foco na configuração RANDAO, mas também aplicáveis a pools de memória criptográfica):
Captura de bilhetes de execução MEV e descentralização:
APS centralizado:
Múltiplos MEV e lista de inclusão:
O que mais precisa ser feito, o que precisa ser ponderado?
Podemos considerar todas as soluções acima como diferentes maneiras de dividir os direitos de participação no stake, organizadas em uma faixa que vai desde economias de escala mais baixas ("dumb-pipe") até economias de escala mais altas ("especialização amigável"). Antes de 2021, todos esses direitos estavam agrupados em um único participante:
O problema central é: qualquer poder significativo que ainda esteja nas mãos das partes interessadas pode, eventualmente, tornar-se um poder "relacionado ao MEV". Queremos que um conjunto de participantes altamente descentralizados possua o máximo de poder possível; isso significa (i) entregar uma grande quantidade de poder às partes interessadas, e (ii) garantir que as partes interessadas sejam o mais descentralizadas possível, o que significa que elas praticamente não têm incentivos de integração impulsionados por economias de escala. Esta é uma tensão difícil de lidar.
Um desafio especial é o MEV de múltiplos blocos: em certos casos, se o vencedor do leilão de execução capturar vários slots consecutivos e não permitir transações relacionadas ao MEV em blocos além do último bloco que controlam, eles podem ganhar mais dinheiro. Se a lista de inclusão os forçar a fazer isso, eles podem tentar contornar isso simplesmente não publicando nenhum bloco durante esses períodos. As pessoas podem criar listas de inclusão incondicionais, se o construtor não fornecer, essa lista de inclusão se tornará diretamente um bloco, mas isso torna a lista de inclusão relacionada ao MEV. A solução aqui pode envolver alguns compromissos, incluindo a aceitação de alguns incentivos de baixo nível para subornar as pessoas a incluir transações na lista de inclusão.
Podemos verificar o FOCIL + APS da seguinte forma. Os stakers continuam a ter o poder da parte esquerda do espectro, enquanto a parte direita do espectro é leiloada ao maior licitante.
BRAID é completamente diferente. A parte dos "stakers" é maior, mas é dividida em duas partes: stakers leves e stakers pesados. Ao mesmo tempo, como as transações são ordenadas em ordem decrescente de taxas prioritárias, a seleção no topo do bloco é na verdade leiloada através do mercado de taxas, e este esquema pode ser visto como semelhante ao PBS.
Por favor, note que a segurança do BRAID depende em grande parte do pool de memória criptográfica; caso contrário, o mecanismo de leilão de bloco pode ser facilmente suscetível a ataques de roubo de estratégia (essencialmente: copiar as transações de outras pessoas, trocar o endereço do destinatário e pagar uma elevada taxa de 0,01%). Essa demanda por privacidade pré-incluída também é a razão pela qual a implementação do PBS é tão complicada.
Por fim, uma versão mais "radical" do FOCIL + APS, por exemplo. O APS determina apenas as opções no final do bloco como segue:
A principal tarefa restante é (i) dedicar-se a consolidar várias propostas e analisar suas consequências, e (ii) combinar essa análise com a compreensão dos objetivos da comunidade Ethereum, ou seja, que formas de centralização ela irá tolerar. Cada proposta individual também precisa completar algum trabalho, por exemplo:
Continuar a dedicar-se ao design de memória de criptomoeda, e atingir um nível em que: o nosso design é robusto e bastante simples, e parece estar pronto para ser incorporado.
Otimizar vários designs de listas que contêm para garantir que (i) não desperdice dados, especialmente no contexto de listas que contêm blobs, assim como (ii) amigável para validadores sem estado.
Mais trabalho sobre o design de leilão ótimo da APS.
Além disso, é importante notar que essas diferentes propostas não são necessariamente pontos de divergência incompatíveis entre si. Por exemplo, a implementação do FOCIL + APS pode facilmente servir como um trampolim para a implementação do BRAID. Uma estratégia conservadora eficaz é a abordagem de "esperar e ver", onde primeiro implementamos uma solução na qual os poderes dos stakers são limitados, a maior parte dos poderes é leiloada, e depois, com o tempo, à medida que entendemos melhor como o mercado de MEV opera na rede em tempo real, aumentamos lentamente o poder dos stakeholders.
Em particular, o gargalo da centralização na staking é:
Centralização da construção de blocos (esta seção)
Centralização de staking por razões econômicas (próxima seção)
Centralização do staking devido ao limite mínimo de 32 ETH (resolvido através da Orbit ou outras tecnologias; consulte as postagens sobre a fusão)
Centralização da staking devido aos requisitos de hardware (resolvido no Verge através de clientes sem estado e do ZK-EVM posterior)
Resolver qualquer um desses quatro problemas aumentará os ganhos de resolver qualquer outro problema.
Além disso, há uma interação entre o pipeline de construção de blocos e a finalização de um único slot, especialmente ao tentar reduzir o tempo do slot. Muitos designs de construção de blocos acabam por aumentar o tempo do slot. Muitos pipelines de construção de blocos envolvem o papel dos provadores em várias etapas do processo. Portanto, vale a pena considerar simultaneamente o pipeline de construção de blocos e a finalização de um único slot.
Reparar a economia de staking
Que problema queremos resolver?
Atualmente, cerca de 30% da oferta de ETH está ativamente em staking. Isso é suficiente para proteger o Ethereum de um ataque de 51%. Se a proporção de ETH em staking se tornar maior, os pesquisadores temem que diferentes situações possam ocorrer: se quase todo o ETH estiver em staking, surgirão riscos. Esses riscos incluem:
O staking passou de uma tarefa lucrativa para os especialistas para uma responsabilidade de todos os detentores de ETH. Assim, os stakers comuns serão menos entusiásticos e optarão pelo método mais simples (na prática, delegando os seus tokens ao operador centralizado mais conveniente).
Se quase todo o ETH estiver em staking, a credibilidade do mecanismo de redução será enfraquecida.
Um único token de staking líquido pode assumir a maior parte da participação acionária, até mesmo assumir o efeito de rede "monetário" do ETH.
O Ethereum emite desnecessariamente cerca de 1 milhão de ETH por ano. No caso de um token de staking líquido obter um efeito de rede dominante, uma grande parte desse valor pode até ser capturada pelo LST.
O que é e como funciona?
Historicamente, uma solução é: se todos inevitavelmente fizerem staking, e os tokens de staking líquido forem inevitáveis, então vamos tornar o staking amigável, para ter tokens de staking líquido que sejam de fato não confiáveis, neutros e o mais descentralizados possível. Uma maneira simples é limitar a penalização do staking a 1/8, o que tornaria 7/8 do ETH em staking não reduzível, tornando-os elegíveis para serem colocados no mesmo token de staking líquido. Outra opção é criar explicitamente um staking em duas camadas: staking "assumindo riscos" (reduzível).
No entanto, uma crítica a esse método é que ele parece ser economicamente equivalente a algo muito mais simples: se a participação se aproxima de um limite superior pré-determinado, a emissão é reduzida drasticamente. O argumento básico é: se acabarmos em um mundo onde a taxa de retorno da camada de risco é de 3,4% e a taxa de retorno da camada sem risco (onde todos participam) é de 2,6%, isso é, na verdade, equivalente ao mundo onde a ETH é apostada com uma taxa de retorno de 0,8% e a simples posse de ETH tem uma taxa de retorno de 0%. A dinâmica da camada de risco, incluindo o total apostado e o grau de centralização, é a mesma em ambos os casos. Portanto, deveríamos fazer algo simples e reduzir a emissão.
A principal objeção a este argumento é se podemos fazer com que a "camada sem risco" ainda tenha alguma função útil e um certo grau de risco (por exemplo, como proposto por Dankrad aqui).
Ambas as sugestões significam alterar a curva de emissão; se a quantidade de ações for excessiva, a taxa de retorno será muito baixa.
Esquerda: Uma proposta de ajuste na curva de emissão apresentada por Justin Drake. Imagem à direita: Outro conjunto de propostas apresentado por Anders Elowsson.
Por outro lado, o staking em dois níveis requer a definição de duas curvas de retorno: (i) a taxa de retorno do staking "básico" (sem risco ou de baixo risco) e (ii) o prémio do staking arriscado. Existem várias maneiras de definir esses parâmetros: por exemplo, se você definir um parâmetro rígido, ou seja, que 1/8 da participação é redutível, então a dinâmica de mercado determinará o prémio da taxa de retorno obtida pela participação redutível.
Outro tema importante aqui é a captura de MEV. Hoje em dia, a receita de MEV (por exemplo, arbitragem DEX, sanduíches...) flui para os proponentes, ou seja, os stakers. Esta é uma receita completamente "opaca" para o protocolo: o protocolo não consegue saber se é uma taxa de juros de 0,01%, 1% ou 20%. De várias perspectivas, a existência desta fonte de receita é bastante inconveniente:
Esta é uma fonte de rendimento instável, pois cada parte interessada só a obtém ao propor um bloco, aproximadamente uma vez a cada 4 meses. Isto incentiva as pessoas a juntarem-se ao fundo para obter um rendimento mais estável.
Isso leva a uma distribuição de incentivos desequilibrada: muitos propostas, poucas provas.
Isso torna difícil implementar o limite de participação: mesmo que a taxa de retorno "oficial" seja zero, a receita apenas de MEV pode ser suficiente para incentivar todos os detentores de ETH a fazer staking. Portanto, a proposta real de limite de participação deve, na verdade, fazer com que os retornos se aproximem de menos infinito. Isso traz mais riscos para os stakers, especialmente para os stakers individuais.
Podemos resolver esses problemas encontrando uma maneira de tornar a receita de MEV clara e capturá-la dentro do protocolo. A proposta mais antiga é a suavização de MEV de Francesco; hoje em dia, é amplamente acreditado que qualquer mecanismo que antecipe os direitos dos proponentes de blocos (ou, de forma mais geral, tenha poder suficiente para capturar quase todo o MEV) pode alcançar o mesmo objetivo.
Quais são as relações com as pesquisas existentes?
Emitir wtf:
Economia de staking do Endgame, caso de posicionamento:
Atributo de nível de emissão, Anders Elowsson:
Limite de tamanho de configuração do validador:
Sobre a reflexão da ideia de múltiplos níveis de staking:
Pledge Arco-íris:
Proposta de staking líquido de Dankrad:
MEV smoothing, autor: Francesco:
MEV burn, autor: Justin Drake:
O que mais precisa ser feito, o que precisa ser ponderado?
A principal tarefa restante é ou concordar em não tomar nenhuma ação e aceitar o risco de que quase todo o ETH esteja dentro do LST, ou finalizar e chegar a um consenso sobre os detalhes e parâmetros de uma das propostas acima. Um resumo geral dos ganhos e riscos é o seguinte:
Como interage com as outras partes do roteiro?
Um ponto de interseção importante está relacionado à estaca individual. Hoje, o VPS mais barato que pode executar um nó Ethereum custa cerca de 60 dólares por mês, principalmente devido ao custo do armazenamento em disco. Para os validadores de 32 ETH (que, no momento da redação deste artigo, equivalem a 84.000 dólares), isso reduz o APY para (60 * 12) / 84000 ~= 0,85%. Se a taxa de retorno total do staking for inferior a 0,85%, então para muitos que estão neste nível, o staking individual não é viável.
Se quisermos que a estaca individual continue viável, isso enfatiza ainda mais a necessidade de reduzir os custos de operação dos nós, que será realizado no Verge: o estado sem estado eliminará a necessidade de espaço de armazenamento, o que pode ser suficiente por si só, e então a prova de validade do EVM L1 tornará os custos insignificantes.
Por outro lado, a queima de MEV pode ser considerada uma ajuda à aposta individual. Embora reduza os retornos de todos, o mais importante é que diminui a variância, tornando a aposta menos semelhante a uma loteria.
Por fim, qualquer alteração na emissão interagirá com outras mudanças fundamentais no design de staking (por exemplo, staking arco-íris). Uma questão particularmente digna de nota é que, se os retornos de staking se tornarem muito baixos, isso significa que devemos escolher entre: (i) reduzir a severidade das penalizações, diminuindo os fatores de dissuasão contra comportamentos inadequados; (ii) manter uma severidade de penalizações elevada, o que aumentará uma série de situações em que mesmo validadores de boa-fé, se infelizmente encontrarem problemas técnicos ou até ataques, podem acidentalmente receber retornos negativos.
Soluções de Camada de Aplicação
A parte acima destacou as mudanças no L1 do Ethereum, que podem resolver riscos de centralização importantes. No entanto, o Ethereum não é apenas um L1, é um ecossistema, e existem estratégias importantes na camada de aplicação que podem ajudar a mitigar os riscos mencionados. Alguns exemplos incluem:
Solução de hardware dedicado para staking — Algumas empresas (como a Dappnode) estão vendendo hardware projetado especificamente para facilitar a operação de nós de staking. Uma maneira de tornar essa solução mais eficaz é levantar uma questão: se os usuários já estão investindo esforço para fazer um dispositivo funcionar e se conectar à internet, que outros serviços (para usuários ou outros) podem ser oferecidos para se beneficiar da descentralização? Exemplos que me vêm à mente incluem (i) execução de um Mestrado em Direito auto-hospedado por razões de soberania e privacidade, bem como (ii) execução de nós de VPN descentralizada.
Staking em equipe —— A solução da Obol permite que várias pessoas façam staking em formato M-of-N. Com o tempo, isso pode se tornar cada vez mais popular, uma vez que a prova de validade do EVM L1 sem estado e posterior reduzirá os custos de operação de mais nós, e cada participante não precisará se preocupar com os benefícios de estar sempre online começando a dominar. Esta é outra forma de reduzir a sobrecarga cognitiva do staking e garantir que o staking individual prospere no futuro.
Airdrop —— Starknet fornece airdrops a stakers individuais. Outros projetos que desejam ter uma comunidade de usuários descentralizada e alinhada com seus valores também podem considerar oferecer airdrops ou descontos a validadores identificados como possíveis detentores individuais de direitos.
Mercado de construção de blocos descentralizado —— Usando uma combinação de ZK, MPC e TEE, é possível criar um construtor de blocos descentralizado, participar e ganhar jogos de leilão APS, enquanto oferece privacidade de pré-confirmação e garantias contra censura para seus usuários. Esta é outra forma de melhorar o bem-estar dos usuários no mundo APS.
Minimização de MEV na camada de aplicação —— Um único aplicativo pode ser construído de forma a "vazar" menos MEV para o L1, reduzindo assim o incentivo para os construtores de blocos criarem algoritmos especializados para coletar MEV. Uma estratégia simples, mas genérica, é que o contrato coloque todas as operações de entrada em uma fila e as execute no próximo bloco, leiloando os direitos de furar a fila, embora isso não seja conveniente e comprometa a compostabilidade. Outras abordagens mais complexas incluem realizar mais trabalho fora da cadeia, como Cowswap faz. Os oráculos também podem ser redesenhados para minimizar o valor extraído pelos oráculos.
Um agradecimento especial a Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes e Max Resnick pelo feedback e revisão, assim como pelas discussões da comunidade ethstakers.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Vitalik: O objetivo chave da fase The Scourge do Ethereum
Autor: Vitalik, fundador do Ethereum; Compilado por: Deng Tong, Jinse Caijing
Nota: Este artigo é a terceira parte da série "Desenvolvimento Futuro do Protocolo Ethereum" publicada recentemente por Vitalik, o fundador do Ethereum, intitulada "Possíveis futuros do protocolo Ethereum, parte 3: A Praga". A segunda parte pode ser encontrada no Jinse Finance "Vitalik: Como o protocolo Ethereum deve evoluir na fase Surge", e a primeira parte pode ser vista em "Quais melhorias ainda podem ser feitas no PoS do Ethereum". Abaixo está o texto completo da terceira parte:
Ethereum L1 enfrenta um dos maiores riscos devido à centralização da prova de participação resultante de pressões econômicas. Se houver economias de escala na participação do mecanismo central de prova de participação, isso naturalmente levará a grandes partes interessadas a dominarem, enquanto as pequenas partes interessadas se retiram para se juntarem a grandes pools de mineração. Isso resulta em um maior risco de ataques de 51%, revisão de transações e outras crises. Além do risco de centralização, também existe o risco de extração de valor: uma pequena parte das pessoas obtém o valor que originalmente iria para os usuários do Ethereum.
No ano passado, nossa compreensão desses riscos aumentou significativamente. É bem conhecido que esse risco existe em dois locais-chave: (i) construção de blocos, e (ii) regulamentos de capital de staking. Participantes maiores podem executar algoritmos mais complexos (“extração MEV”) para gerar blocos, resultando em uma receita de bloco mais alta para eles. Participantes grandes também podem resolver de maneira mais eficaz a inconveniência do capital bloqueado, liberando fundos como tokens de staking líquidos (LST) para outros. Além dos problemas diretos entre pequenos e grandes stakers, também há a questão de se (ou se haverá) uma superabundância de staking de ETH.
Roteiro Scourge 2023
Este ano, a construção do blockchain fez progressos significativos, sendo o mais notável a fusão da "lista de inclusão do comitê juntamente com algumas soluções de ordenação direcionadas" como a solução ideal, bem como a importante pesquisa sobre a economia da prova de participação, incluindo modelos de staking de duas camadas e a redução da emissão para limitar a percentagem de ETH em staking.
Os principais objetivos da praga
Este artigo é dividido em três partes
Reparar construção de blocos
Que problema queremos resolver?
Atualmente, a construção de blocos no Ethereum é realizada principalmente através da separação entre o propositor e o construtor fora do protocolo MEVBoost. Quando um validador tem a oportunidade de propor um bloco, ele delega a tarefa de escolher o conteúdo do bloco a participantes especializados chamados construtores. A tarefa de selecionar o conteúdo do bloco que maximiza a receita é intensiva em economias de escala: requer algoritmos especializados para determinar quais transações incluir, a fim de extrair o máximo valor possível das ferramentas financeiras na cadeia e das transações dos usuários que interagem com elas (o que é conhecido como "extração de MEV"). Os validadores enfrentam uma tarefa de "dumb-pipe" relativamente leve em termos de economias de escala, que consiste em ouvir os lances e aceitar o lance mais alto, além de outras responsabilidades como a prova.
Gráfico programático do que o MEVBoost está fazendo: construtores dedicados assumem as tarefas em vermelho, enquanto os stakeholders assumem as tarefas em azul.
Existem várias versões, incluindo "Separação de Proponentes e Construtores" (PBS) e "Separação de Proponentes e Validadores" (APS). A diferença entre elas está relacionada a detalhes mais finos, ou seja, quais responsabilidades são assumidas por qual dos dois participantes: de forma geral, no PBS, os validadores ainda propõem blocos, mas recebem a carga útil do construtor, enquanto no APS, toda a responsabilidade do slot recai sobre o construtor. Recentemente, o APS tem sido mais favorecido do que o PBS, pois reduz ainda mais o incentivo para os proponentes e construtores estarem juntos. Note que o APS se aplica apenas a blocos de execução que contêm transações; blocos de consenso que contêm dados relacionados à prova de participação (como provas) ainda serão aleatoriamente alocados aos validadores.
Essa separação de poderes ajuda a manter a descentralização dos validadores, mas tem um custo importante: os participantes que executam tarefas "especializadas" podem facilmente se tornar muito centralizados. Esta é a construção de blocos do Ethereum hoje:
Dois participantes estão escolhendo o conteúdo de cerca de 88% dos blocos do Ethereum. E se esses dois participantes decidirem revisar as transações? A resposta não é tão ruim quanto parece: eles não podem reestruturar os blocos, portanto, você não precisa de 51% de revisão para impedir que as transações sejam incluídas: você precisa de 100%. Com um mecanismo de revisão de 88%, os usuários em média precisam esperar 9 slots (tecnicamente, uma média de 114 segundos, em vez de 6 segundos). Para alguns casos de uso, esperar por certas transações por dois minutos ou até cinco minutos pode ser suficiente. Mas para outros casos de uso, como liquidações DeFi, mesmo a capacidade de atrasar a inclusão das transações de outras pessoas por alguns blocos representa um risco significativo de manipulação de mercado.
As estratégias que os construtores de blocos podem usar para maximizar a receita também podem ter outros efeitos negativos sobre os usuários. Um "ataque de sanduíche" pode causar perdas significativas aos usuários que realizam transações de tokens devido ao deslizamento. Para bloquear as transações introduzidas por esses ataques, os preços do Gas de outros usuários aumentaram.
O que é e como funciona?
A solução líder é dividir ainda mais a tarefa de produção de blocos: vamos devolver a tarefa de seleção de transações aos proponentes (ou seja, os stakers), enquanto os construtores só podem escolher a ordem e inserir algumas de suas próprias transações. É isso que a lista de inclusão quer fazer.
No tempo T, um validador selecionado aleatoriamente cria uma lista de inclusão, ou seja, uma lista de transações válidas com base no estado atual da blockchain. No tempo T+1, o construtor de bloco (que pode ter sido escolhido antecipadamente através de um mecanismo de leilão dentro do protocolo) cria um bloco. Este bloco precisa incluir cada transação da lista de inclusão, mas eles podem escolher a ordem e adicionar suas próprias transações.
A proposta da Lista de Inclusão de Forks Obrigatórios (FOCIL) envolve um comitê composto por vários criadores de listas de inclusão para cada bloco. Para atrasar uma transação em um bloco, k dos criadores de listas de inclusão, entre k (por exemplo, k = 16), devem revisar a transação. O FOCIL, combinado com o proponente final selecionado por leilão, deve incluir a lista de inclusão, mas pode ser reorganizado e novas transações podem ser adicionadas, geralmente chamadas de "FOCIL + APS".
Outra maneira de resolver o problema é através de múltiplos proponentes em paralelo (MCP), como o BRAID. O BRAID tenta evitar a divisão do papel de proponente de bloco em partes de baixa e alta economia de escala, mas tenta distribuir o processo de produção de blocos entre muitos participantes, de modo que cada proponente só precise ter um nível médio de complexidade para maximizar sua receita. O funcionamento do MCP é permitir que k proponentes paralelos gerem listas de transações e, em seguida, usem um algoritmo determinístico (por exemplo, ordenação por taxas, da mais alta para a mais baixa) para escolher a ordem.
BRAID não busca implementar a proposta de bloco dumb-pipe do software padrão como o melhor objetivo. Existem duas razões fáceis de entender pelas quais isso não pode ser feito:
Ataque de arbitragem tardio: Suponha que o tempo médio para o proponente se comprometer é T, e o tempo que você pode enviar pela última vez e ainda ser incluído é cerca de T+1. Agora, digamos que em uma bolsa centralizada, o preço ETH / USDC vai de $2500 a $2502 entre T e T+1. Os proponentes podem esperar um segundo extra e, em seguida, adicionar transações adicionais à arbitragem de exchanges descentralizadas on-chain, ganhando até US $ 2 em lucro por ETH. Proponentes experientes com boas conexões à rede estão mais bem equipados para fazer isso.
No BRAID, o provador ainda pode ser separado e operar como uma função de tubo estúpido.
Além desses dois extremos, existe uma série de possíveis designs que se situam entre os dois. Por exemplo, você pode leiloar um papel que tenha apenas o direito de anexar a um bloco, sem o direito de reordenar ou preceder. Você pode até permitir que eles anexem ou precedam, mas não insiram no meio ou reordenem. O apelo dessas técnicas reside no fato de que os vencedores do mercado de leilões podem ser muito concentrados, portanto, reduzir sua autoridade traz muitos benefícios.
memória pool criptografia
Uma tecnologia que é crítica para a implementação bem-sucedida de muitos desses projetos (especificamente, versões BRAID ou APS, que têm restrições rígidas na funcionalidade de leilão) são os mempools criptografados. Um mempool de criptografia é uma técnica na qual um usuário transmite sua transação de forma criptografada com algum tipo de prova de validade, e a transação está contida em um bloco em forma criptografada sem que o construtor de blocos conheça seu conteúdo. Os detalhes da transação serão anunciados posteriormente.
O principal desafio de implementar um pool de memória criptografada é propor um design que assegure que todas as transações serão divulgadas mais tarde: um simples esquema de "submissão e divulgação" não funciona, pois se a divulgação é voluntária, a própria escolha de divulgar ou não divulgar tem um efeito de "último impulsionador" sobre os blocos que podem ser explorados. As duas técnicas principais são (i) decriptação por limiar e (ii) criptografia atrasada, que é um primitivo intimamente relacionado à função de atraso verificável (VDF).
Quais as ligações com a pesquisa existente?
Explicação sobre a centralização de MEV e construtores:
MEVBoost：
PBS consagrado (soluções propostas precocemente para esses problemas):
Lista de leituras relacionadas à lista de inclusão de Mike Neuder:
Lista de EIPs incluídos:
FOCIL：
Demonstração BRAID de Max Resnick:
“A prioridade é o que você precisa”, autor: Dan Robinson:
Sobre ferramentas e protocolos de múltiplos proponentes:
VDFResearch.org：
Funções de atraso verificáveis e ataques (com foco na configuração RANDAO, mas também aplicáveis a pools de memória criptográfica):
Captura de bilhetes de execução MEV e descentralização:
APS centralizado:
Múltiplos MEV e lista de inclusão:
O que mais precisa ser feito, o que precisa ser ponderado?
Podemos considerar todas as soluções acima como diferentes maneiras de dividir os direitos de participação no stake, organizadas em uma faixa que vai desde economias de escala mais baixas ("dumb-pipe") até economias de escala mais altas ("especialização amigável"). Antes de 2021, todos esses direitos estavam agrupados em um único participante:
O problema central é: qualquer poder significativo que ainda esteja nas mãos das partes interessadas pode, eventualmente, tornar-se um poder "relacionado ao MEV". Queremos que um conjunto de participantes altamente descentralizados possua o máximo de poder possível; isso significa (i) entregar uma grande quantidade de poder às partes interessadas, e (ii) garantir que as partes interessadas sejam o mais descentralizadas possível, o que significa que elas praticamente não têm incentivos de integração impulsionados por economias de escala. Esta é uma tensão difícil de lidar.
Um desafio especial é o MEV de múltiplos blocos: em certos casos, se o vencedor do leilão de execução capturar vários slots consecutivos e não permitir transações relacionadas ao MEV em blocos além do último bloco que controlam, eles podem ganhar mais dinheiro. Se a lista de inclusão os forçar a fazer isso, eles podem tentar contornar isso simplesmente não publicando nenhum bloco durante esses períodos. As pessoas podem criar listas de inclusão incondicionais, se o construtor não fornecer, essa lista de inclusão se tornará diretamente um bloco, mas isso torna a lista de inclusão relacionada ao MEV. A solução aqui pode envolver alguns compromissos, incluindo a aceitação de alguns incentivos de baixo nível para subornar as pessoas a incluir transações na lista de inclusão.
Podemos verificar o FOCIL + APS da seguinte forma. Os stakers continuam a ter o poder da parte esquerda do espectro, enquanto a parte direita do espectro é leiloada ao maior licitante.
BRAID é completamente diferente. A parte dos "stakers" é maior, mas é dividida em duas partes: stakers leves e stakers pesados. Ao mesmo tempo, como as transações são ordenadas em ordem decrescente de taxas prioritárias, a seleção no topo do bloco é na verdade leiloada através do mercado de taxas, e este esquema pode ser visto como semelhante ao PBS.
Por favor, note que a segurança do BRAID depende em grande parte do pool de memória criptográfica; caso contrário, o mecanismo de leilão de bloco pode ser facilmente suscetível a ataques de roubo de estratégia (essencialmente: copiar as transações de outras pessoas, trocar o endereço do destinatário e pagar uma elevada taxa de 0,01%). Essa demanda por privacidade pré-incluída também é a razão pela qual a implementação do PBS é tão complicada.
Por fim, uma versão mais "radical" do FOCIL + APS, por exemplo. O APS determina apenas as opções no final do bloco como segue:
A principal tarefa restante é (i) dedicar-se a consolidar várias propostas e analisar suas consequências, e (ii) combinar essa análise com a compreensão dos objetivos da comunidade Ethereum, ou seja, que formas de centralização ela irá tolerar. Cada proposta individual também precisa completar algum trabalho, por exemplo:
Além disso, é importante notar que essas diferentes propostas não são necessariamente pontos de divergência incompatíveis entre si. Por exemplo, a implementação do FOCIL + APS pode facilmente servir como um trampolim para a implementação do BRAID. Uma estratégia conservadora eficaz é a abordagem de "esperar e ver", onde primeiro implementamos uma solução na qual os poderes dos stakers são limitados, a maior parte dos poderes é leiloada, e depois, com o tempo, à medida que entendemos melhor como o mercado de MEV opera na rede em tempo real, aumentamos lentamente o poder dos stakeholders.
Em particular, o gargalo da centralização na staking é:
Resolver qualquer um desses quatro problemas aumentará os ganhos de resolver qualquer outro problema.
Além disso, há uma interação entre o pipeline de construção de blocos e a finalização de um único slot, especialmente ao tentar reduzir o tempo do slot. Muitos designs de construção de blocos acabam por aumentar o tempo do slot. Muitos pipelines de construção de blocos envolvem o papel dos provadores em várias etapas do processo. Portanto, vale a pena considerar simultaneamente o pipeline de construção de blocos e a finalização de um único slot.
Reparar a economia de staking
Que problema queremos resolver?
Atualmente, cerca de 30% da oferta de ETH está ativamente em staking. Isso é suficiente para proteger o Ethereum de um ataque de 51%. Se a proporção de ETH em staking se tornar maior, os pesquisadores temem que diferentes situações possam ocorrer: se quase todo o ETH estiver em staking, surgirão riscos. Esses riscos incluem:
O que é e como funciona?
Historicamente, uma solução é: se todos inevitavelmente fizerem staking, e os tokens de staking líquido forem inevitáveis, então vamos tornar o staking amigável, para ter tokens de staking líquido que sejam de fato não confiáveis, neutros e o mais descentralizados possível. Uma maneira simples é limitar a penalização do staking a 1/8, o que tornaria 7/8 do ETH em staking não reduzível, tornando-os elegíveis para serem colocados no mesmo token de staking líquido. Outra opção é criar explicitamente um staking em duas camadas: staking "assumindo riscos" (reduzível).
No entanto, uma crítica a esse método é que ele parece ser economicamente equivalente a algo muito mais simples: se a participação se aproxima de um limite superior pré-determinado, a emissão é reduzida drasticamente. O argumento básico é: se acabarmos em um mundo onde a taxa de retorno da camada de risco é de 3,4% e a taxa de retorno da camada sem risco (onde todos participam) é de 2,6%, isso é, na verdade, equivalente ao mundo onde a ETH é apostada com uma taxa de retorno de 0,8% e a simples posse de ETH tem uma taxa de retorno de 0%. A dinâmica da camada de risco, incluindo o total apostado e o grau de centralização, é a mesma em ambos os casos. Portanto, deveríamos fazer algo simples e reduzir a emissão.
A principal objeção a este argumento é se podemos fazer com que a "camada sem risco" ainda tenha alguma função útil e um certo grau de risco (por exemplo, como proposto por Dankrad aqui).
Ambas as sugestões significam alterar a curva de emissão; se a quantidade de ações for excessiva, a taxa de retorno será muito baixa.
Esquerda: Uma proposta de ajuste na curva de emissão apresentada por Justin Drake. Imagem à direita: Outro conjunto de propostas apresentado por Anders Elowsson.
Por outro lado, o staking em dois níveis requer a definição de duas curvas de retorno: (i) a taxa de retorno do staking "básico" (sem risco ou de baixo risco) e (ii) o prémio do staking arriscado. Existem várias maneiras de definir esses parâmetros: por exemplo, se você definir um parâmetro rígido, ou seja, que 1/8 da participação é redutível, então a dinâmica de mercado determinará o prémio da taxa de retorno obtida pela participação redutível.
Outro tema importante aqui é a captura de MEV. Hoje em dia, a receita de MEV (por exemplo, arbitragem DEX, sanduíches...) flui para os proponentes, ou seja, os stakers. Esta é uma receita completamente "opaca" para o protocolo: o protocolo não consegue saber se é uma taxa de juros de 0,01%, 1% ou 20%. De várias perspectivas, a existência desta fonte de receita é bastante inconveniente:
Podemos resolver esses problemas encontrando uma maneira de tornar a receita de MEV clara e capturá-la dentro do protocolo. A proposta mais antiga é a suavização de MEV de Francesco; hoje em dia, é amplamente acreditado que qualquer mecanismo que antecipe os direitos dos proponentes de blocos (ou, de forma mais geral, tenha poder suficiente para capturar quase todo o MEV) pode alcançar o mesmo objetivo.
Quais são as relações com as pesquisas existentes?
Emitir wtf:
Economia de staking do Endgame, caso de posicionamento:
Atributo de nível de emissão, Anders Elowsson:
Limite de tamanho de configuração do validador:
Sobre a reflexão da ideia de múltiplos níveis de staking:
Pledge Arco-íris:
Proposta de staking líquido de Dankrad:
MEV smoothing, autor: Francesco:
MEV burn, autor: Justin Drake:
O que mais precisa ser feito, o que precisa ser ponderado?
A principal tarefa restante é ou concordar em não tomar nenhuma ação e aceitar o risco de que quase todo o ETH esteja dentro do LST, ou finalizar e chegar a um consenso sobre os detalhes e parâmetros de uma das propostas acima. Um resumo geral dos ganhos e riscos é o seguinte:
Como interage com as outras partes do roteiro?
Um ponto de interseção importante está relacionado à estaca individual. Hoje, o VPS mais barato que pode executar um nó Ethereum custa cerca de 60 dólares por mês, principalmente devido ao custo do armazenamento em disco. Para os validadores de 32 ETH (que, no momento da redação deste artigo, equivalem a 84.000 dólares), isso reduz o APY para (60 * 12) / 84000 ~= 0,85%. Se a taxa de retorno total do staking for inferior a 0,85%, então para muitos que estão neste nível, o staking individual não é viável.
Se quisermos que a estaca individual continue viável, isso enfatiza ainda mais a necessidade de reduzir os custos de operação dos nós, que será realizado no Verge: o estado sem estado eliminará a necessidade de espaço de armazenamento, o que pode ser suficiente por si só, e então a prova de validade do EVM L1 tornará os custos insignificantes.
Por outro lado, a queima de MEV pode ser considerada uma ajuda à aposta individual. Embora reduza os retornos de todos, o mais importante é que diminui a variância, tornando a aposta menos semelhante a uma loteria.
Por fim, qualquer alteração na emissão interagirá com outras mudanças fundamentais no design de staking (por exemplo, staking arco-íris). Uma questão particularmente digna de nota é que, se os retornos de staking se tornarem muito baixos, isso significa que devemos escolher entre: (i) reduzir a severidade das penalizações, diminuindo os fatores de dissuasão contra comportamentos inadequados; (ii) manter uma severidade de penalizações elevada, o que aumentará uma série de situações em que mesmo validadores de boa-fé, se infelizmente encontrarem problemas técnicos ou até ataques, podem acidentalmente receber retornos negativos.
Soluções de Camada de Aplicação
A parte acima destacou as mudanças no L1 do Ethereum, que podem resolver riscos de centralização importantes. No entanto, o Ethereum não é apenas um L1, é um ecossistema, e existem estratégias importantes na camada de aplicação que podem ajudar a mitigar os riscos mencionados. Alguns exemplos incluem:
Um agradecimento especial a Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes e Max Resnick pelo feedback e revisão, assim como pelas discussões da comunidade ethstakers.