Um dos maiores riscos para o Ethereum L1 é a centralização do proof-of-stake devido a pressões econômicas. Se houver economias de escala na participação nos mecanismos centrais de proof-of-stake, isso naturalmente levaria a grandes participantes dominantes e pequenos participantes desistindo para se juntar a grandes pools. Isso leva a um maior risco de ataques de 51%, censura de transações e outras crises. Além do risco de centralização, há também riscos de extração de valor: um pequeno grupo capturando valor que, de outra forma, iria para os usuários do Ethereum.

No último ano, a nossa compreensão desses riscos aumentou consideravelmente. É bem compreendido que existem dois locais-chave onde esse risco existe: (i) construção de blocos e (ii) fornecimento de capital para apostas. Atores maiores podem se dar ao luxo de executar algoritmos mais sofisticados (extração de 'MEV') para gerar blocos, proporcionando-lhes uma receita por bloco mais alta. Atores muito grandes também podem lidar de forma mais eficaz com o incômodo de ter seu capital bloqueado, liberando-o para outros como um token de apostas líquidas (LST). Além das questões diretas de apostadores pequenos versus grandes, também existe a questão de se há (ou haverá) muito ETH apostado.

O Flagelo, roteiro de 2023

Este ano, houve avanços significativos na construção de blocos, especialmente a convergência em 'listas de inclusão do comitê mais alguma solução direcionada para a ordem' como a solução ideal, bem como pesquisas significativas sobre economia de prova de participação, incluindo ideias como modelos de participação em dois níveis e redução da emissão para limitar a porcentagem de ETH apostada.

The Scourge: objetivos-chave

• Minimizar os riscos de centralização na camada de staking do Ethereum (nomeadamente, na construção de blocos e na provisão de capital, também conhecida como MEV e pools de staking)
• Minimize os riscos de extração excessiva de valor dos utilizadores

Neste capítulo

• Corrigindo o pipeline de construção de blocos
• Corrigindo a economia de staking
• Soluções de camada de aplicação

Corrigindo o pipeline de construção de blocos

Que problema estamos a resolver?

Hoje em dia, a construção de blocos Ethereum é em grande parte feita através da separação extra-protocolo do construtor de propser comMEVBoostQuando um validador tem a oportunidade de propor um bloco, eles leiloam o trabalho de escolher o conteúdo do bloco para atores especializados chamados construtores. A tarefa de escolher o conteúdo do bloco que maximiza a receita é muito intensiva em termos de economias de escala: algoritmos especializados são necessários para determinar quais transações incluir, a fim de extrair o máximo valor possível dos gadgets financeiros on-chain e das transações dos usuários que interagem com eles (isto é o que é chamado de 'extração de MEV'). Os validadores ficam com a tarefa relativamente leve em termos de economias de escala de 'tubo burro' de ouvir as ofertas e aceitar a oferta mais alta, bem como outras responsabilidades como a atestação.

Diagrama estilizado do que o MEVBoost está fazendo: construtores especializados assumem as tarefas em vermelho, e os apostadores assumem as tarefas em azul.

Existem várias versões disto, incluindo “separação do proponente-construtor“ (PBS) e “separação de atestador-propositor” (APS). A diferença entre eles tem a ver com detalhes refinados sobre quais responsabilidades vão para cada um dos dois atores: em PBS, os validadores ainda propõem blocos, mas recebem a carga dos construtores, e em APS, o slot inteiro torna-se responsabilidade do construtor. Recentemente, APS é preferido a PBS, porque reduz ainda mais os incentivos para que os proponentes se localizem junto aos construtores. Note que APS só se aplicaria a blocos de execução, que contêm transações; blocos de consenso, que contêm dados relacionados ao proof-of-stake, como atestações, ainda seriam atribuídos aleatoriamente aos validadores.

Esta separação de poderes ajuda a manter os validadores descentralizados, mas tem um custo importante: os atores que estão a fazer as tarefas "especializadas" podem facilmente tornar-se muito centralizados. Aqui está a construção de blocos Ethereum hoje:

Dois atores estão escolhendo o conteúdo de cerca de 88% dos blocos do Ethereum. E se esses dois atores decidirem censurar uma transação? A resposta não é tão ruim quanto parece: eles não podem reorganizar blocos, então você não precisa de 51% de censura para impedir que uma transação seja incluída: você precisa de 100%. Com 88% de censura, um usuário precisaria esperar em média 9 slots para ser incluído (tecnicamente, uma média de 114 segundos, em vez de 6 segundos). Para alguns casos de uso, esperar dois ou mesmo cinco minutos para certas transações está tudo bem. Mas para outros casos de uso, como liquidações de defi, até mesmo a capacidade de atrasar a inclusão da transação de outra pessoa por alguns blocos é um risco significativo de manipulação de mercado.

As estratégias que os construtores de blocos podem empregar para maximizar a receita também podem ter outras consequências negativas para os utilizadores. A “ataque sanduíche"poderia fazer com que os utilizadores que fazem trocas de tokens sofram perdas significativas de derrapagem. As transações introduzidas para fazer esses ataques entopem a cadeia, aumentando os preços do gás para outros utilizadores."

O que é isto e como funciona?

A solução líder é dividir ainda mais a tarefa de produção de blocos: damos a tarefa de escolher transações de volta ao proponente (ou seja, um staker), e o construtor só pode escolher a ordem e inserir algumas transações próprias. Isto é o que listas de inclusãoprocurar fazer.

No momento T, um validador selecionado aleatoriamente cria uma lista de inclusão, uma lista de transações válidas dadas as atuais estado da blockchain naquele momento. No momento T+1, um construtor de blocos, talvez escolhido através de um mecanismo de leilão em protocolo antecipadamente, cria um bloco. Este bloco é obrigado a incluir todas as transações na lista de inclusão, mas eles podem escolher a ordem e podem adicionar suas próprias transações.

As propostas de listas de inclusão forçada de escolha de fork (FOCIL) envolvem um comitê de vários criadores de listas de inclusão por bloco. Para atrasar uma transação em um bloco, k dos k criadores da lista de inclusão (por exemplo, k = 16 ) teriam que censurar a transação. A combinação de FOCIL com um proponente final escolhido por leilão que é obrigado a incluir as listas de inclusão, mas pode reordenar e adicionar novas transações, é frequentemente chamada de "FOCIL + APS".

Uma abordagem diferente para o problema são esquemas de proponentes concorrentes múltiplos (MCP) como BRAID. BRAID procura evitar a divisão do papel do proponente de bloco em uma parte de baixa economia de escala e uma parte de alta economia de escala, e em vez disso tenta distribuir o processo de produção de bloco entre muitos atores, de tal forma que cada proponente só precisa ter uma quantidade média de sofisticação para maximizar sua receita. MCP funciona tendo k proponentes paralelos gerando listas de transações e, em seguida, usando um algoritmo determinístico (por exemplo, ordenar por taxa mais alta a mais baixa) para escolher a ordem.

A BRAID não busca alcançar o objetivo de que os proponentes de blocos dumb-pipe executem o software padrão de forma ótima. Duas razões fáceis de entender pelas quais isso não pode ser feito são:

1. Ataques de arbitragem de última hora: suponha que o tempo médio que os proponentes enviam é T, e a última vez possível que você pode enviar e ainda ser incluído é em torno de T+1. Agora, suponha que em exchanges centralizadas, o preço ETH/USDC se move de $2500 para $2502 entre T e T+1. Um proponente pode esperar um segundo extra e adicionar uma transação adicional à arbitragem de exchanges descentralizadas on-chain, reivindicando até US $ 2 por ETH em lucro. Proponentes sofisticados que estão muito bem conectados à rede têm mais capacidade de fazer isso.
2. Fluxo de ordem exclusivo: os usuários têm o incentivo de enviar transações diretamente para um único proponente, a fim de minimizar sua vulnerabilidade a front-running e outros ataques. Proponentes sofisticados têm uma vantagem porque podem configurar infraestrutura para aceitar essas transações diretas do usuário, e eles têm reputações mais fortes, para que os usuários que lhes enviam transações possam confiar que o proponente não irá traí-los e front-run (isso pode ser mitigado com hardware confiável, mas então o hardware confiável tem suposições de confiança próprias)

Em BRAID, os atestadores ainda podem ser separados e executados como uma funcionalidade de tubo burro.

Além desses dois extremos, há um espectro de possíveis designs intermediários. Por exemplo, você poderia leiloar uma função que apenas tem o direito de acrescentar a um bloco, e não reordenar ou anteceder. Você poderia até permitir que eles acrescentassem ou antecedessem, mas não inserissem no meio ou reordenassem. A atração dessas técnicas é que os vencedores do mercado de leilões são provavelmentesermuito concentrado, e assim há muitos benefícios em reduzir a sua autoridade.

Mempools criptografadas

Uma tecnologia que é crucial para a implementação bem-sucedida de muitos desses projetos (especificamente, seja BRAID ou uma versão de APS onde existem limites estritos sobre a capacidade que está sendo leiloada) são mempools criptografados. Os mempools criptografados são uma tecnologia onde os usuários transmitem suas transações em formato criptografado, juntamente com algum tipo de prova de sua validade, e as transações são incluídas em blocos em formato criptografado, sem que o construtor de bloco saiba o conteúdo. O conteúdo das transações é revelado posteriormente.

O principal desafio na implementação de mempools criptografados é criar um design que garanta que as transações sejam reveladas posteriormente: um esquema simples de 'compromisso e revelação' não funciona, porque se a revelação for voluntária, o ato de escolher revelar ou não revelar é em si uma espécie de influência do 'último jogador' em um bloco que poderia ser explorado. As duas técnicas principais para isso são (i) decifração de limiar, e (ii) atrasar a criptografia, um primitivo intimamente relacionado com funções de atraso verificáveis (VDFs).

Quais são alguns links para pesquisas existentes?

• Explorador sobre MEV e centralização do construtor: https://vitalik.eth.limo/general/2024/05/17/decentralization.html#mev-and-builder-dependence
• MEVBoost: https://github.com/flashbots/mev-boost
• Em PBS sagrado (uma solução proposta anteriormente para esses problemas):https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710
• Lista de leituras relacionadas à lista de inclusão de Mike Neuder:https://gist.github.com/michaelneuder/dfe5699cb245bc99fbc718031c773008
• Lista de Inclusão EIP:https://eips.ethereum.org/EIPS/eip-7547
• FOCIL: https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870
• Apresentação sobre BRAID por Max Resnick:https://www.youtube.com/watch?v=mJLERWmQ2uw
• "Prioridade é tudo que você precisa", por Dan Robinson:https://www.paradigm.xyz/2024/06/priority-is-all-you-need
• Sobre dispositivos e protocolos de múltiplos propositores:https://hackmd.io/xz1UyksETR-pCsazePMAjw
• VDFresearch.org: https://vdfresearch.org/
• Funções de atraso verificáveis e ataques (foca nas configurações do RANDAO, mas também aplicável a mempools criptografadas):https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365
• Captura de MEV e Descentralização em Bilhetes de Execução: https://www.arxiv.org/pdf/2408.11255
• Centralização em APS: https://arxiv.org/abs/2408.03116
• Multi-block MEV e listas de inclusão: https://x.com/%5fcharlienoyes/status/1806186662327689441

O que falta fazer e quais são os compromissos?

Podemos pensar em todos os esquemas acima como diferentes formas de dividir a autoridade envolvida no staking, organizadas em um espectro de economias de escala menores ("dumb-pipe") a economias de escala maiores ("especialização-amigável"). Antes de 2021, todas essas autoridades estavam agrupadas em um único ator:

O enigma central é o seguinte: qualquer autoridade significativa que permaneça nas mãos dos interessados, é uma autoridade que pode acabar sendo "relevante para o MEV". Queremos que um conjunto altamente descentralizado de atores tenha o máximo de autoridade possível; Isso implica (i) colocar muita autoridade nas mãos dos stakers, e (ii) garantir que os stakers sejam o mais descentralizados possível, o que significa que eles têm poucos incentivos impulsionados por economias de escala para consolidar. Esta é uma tensão difícil de navegar.

Um desafio particular é o MEV multi-bloco: em alguns casos, os vencedores de leilões de execução podem ganhar ainda mais dinheiro se capturarem múltiplas slots seguidas e não permitirem transações relevantes para o MEV em blocos que não sejam o último que controlam. Se as listas de inclusão os forçarem a fazê-lo, podem tentar contornar isso por não publicarem qualquer bloco durante essas slots. Poder-se-ia criar listas de inclusão incondicionais, que se tornam diretamente o bloco se o construtor não fornecer um, mas isto inclui na lista relevante para MEV. A solução aqui pode envolver algum compromisso que envolve aceitar algum baixo grau de incentivo para subornar as pessoas a incluir transações em uma lista de inclusão e esperar que não seja alto o suficiente para levar à terceirização em massa.

Podemos ver FOCIL + APS da seguinte forma. Os validadores continuam a ter autoridade na parte esquerda do espectro, enquanto a parte direita do espectro é leiloada para o licitante mais alto.

BRAID é bastante diferente. A peça do 'staker' é maior, mas é dividida em duas partes: 'light stakers' e 'heavy stakers'. Enquanto isso, porque as transações são ordenadas em ordem decrescente da taxa de prioridade, a escolha do topo do bloco é leiloada de facto através do mercado de taxas, num esquema que pode ser visto como análogo aenraizado PBS.

Note que a segurança do BRAID depende fortemente de mempools criptografados; caso contrário, o mecanismo de leilão no topo do bloco se torna vulnerá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 taxa 0,01% mais alta). Essa necessidade de privacidade pré-inclusão também é a razão pela qual a implementação do PBS consagrado é tão complicada.

Finalmente, versões mais “agressivas” de FOCIL + APS, por exemplo, a opção em que APS apenas determina o final do bloco, ficam assim:

A principal tarefa restante é (i) trabalhar na solidificação das várias propostas e analisar suas consequências, e (ii) combinar essa análise com a compreensão dos objetivos da comunidade Ethereum em termos de que formas de centralização ela irá tolerar. Há também trabalho a ser feito em cada proposta individual, como:

• Continuando o trabalho em designs de mempool criptografados, e chegando ao ponto em que temos um design que é robusto e razoavelmente simples, e plausivelmente pronto para inclusão.
• Otimizar o design de várias listas de inclusão para garantir que (i) não desperdice dados, especialmente no contexto de listas de inclusão que cobrem blobs e (ii) seja amigável para validadores sem estado.
• Mais trabalho no design de leilão ótimo para APS.

Além disso, vale a pena notar que essas diferentes propostas não são necessariamente forks incompatíveis uns dos outros. Por exemplo, a implementação de FOCIL + APS poderia facilmente servir como um trampolim para a implementação de BRAID. Uma estratégia conservadora válida seria uma abordagem de “esperar para ver”, onde primeiro implementamos uma solução em que a autoridade dos stakers é limitada e a maior parte da autoridade é leiloada, e depois aumentamos lentamente a autoridade dos stakers ao longo do tempo à medida que aprendemos mais sobre a operação do mercado MEV na rede ao vivo.

Como interage com outras partes do roteiro?

Existem interações positivas entre resolver um gargalo de centralização de staking e resolver os outros. Para dar uma analogia, imagine um mundo onde iniciar sua própria empresa exigisse cultivar sua própria comida, fabricar seus próprios computadores e ter seu próprio exército. Neste mundo, apenas algumas empresas poderiam existir. Resolver um dos três problemas ajudaria a situação, mas apenas um pouco. Resolver dois problemas ajudaria mais do que o dobro de resolver um. E resolver três seria muito mais do que três vezes mais útil - se você é um empreendedor solo, ou os 3/3 problemas são resolvidos ou você não tem chance.

Especificamente, os gargalos de centralização para o staking são:

• Centralização da construção de blocos (esta seção)
• Centralização de staking por motivos econômicos (próxima seção)
• Centralização do staking devido ao mínimo de 32 ETH (resolvido com Orbit ou outras técnicas; consulte a publicação sobre oFusão)
• Centralização do staking devido aos requisitos de hardware (resolvido no Verge, com clientes sem estado e posteriormente ZK-EVMs)

Resolver qualquer um dos quatro aumenta os ganhos de resolver qualquer um dos outros.

Além disso, existem interações entre o pipeline de construção de blocos e o design de finalidade de slot único, especialmente no contexto de tentar reduzir os tempos de slot. Muitos designs de pipeline de construção de blocos acabam aumentando os tempos de slot. Muitos pipelines de construção de blocos envolvem papéis para atestadores em vários passos do processo. Por essa razão, pode valer a pena pensar nos pipelines de construção de blocos e na finalidade do slot único simultaneamente.

Corrigindo a economia de staking

Que problema estamos a resolver?

Hoje, cerca de 30% do fornecimento de ETH está participando ativamente no staking. Isso é muito mais do que suficiente para proteger o Ethereum de 51% de ataques. Se a porcentagem de ETH apostada crescer muito mais, os pesquisadores temem um cenário diferente: os riscos que surgiriam se quase toda a ETH se tornasse apostada. Estes riscos incluem:

• O staking deixa de ser uma tarefa lucrativa para especialistas e passa a ser um dever para todos os detentores de ETH. Portanto, o staker médio estaria muito menos entusiasmado e escolheria a abordagem mais fácil (realisticamente, delegando seus tokens ao operador centralizado que oferece mais conveniência).
• A credibilidade do mecanismo de corte enfraquece se quase todo o ETH for apostado
• Um único token de stake líquido pode assumir a maior parte da participação e até mesmo assumir os efeitos de rede de "dinheiro" do próprio ETH
• Ethereum está a emitir desnecessariamente cerca de ~1m ETH/ano. No caso em que um token de participação líquida obtém um efeito de rede dominante, uma grande parte deste valor poderia potencialmente até ser capturada pelo LST.

O que é isso e como funciona?

Historicamente, uma classe de solução tem sido: se todos os staking são inevitáveis e um token de staking líquido é inevitável, então vamos tornar o staking amigável para ter um token de staking líquido que seja realmente confiável, neutro e maximamente descentralizado. Uma maneira simples de fazer isso é limitar as penalidades de staking, por exemplo, a 1/8, o que tornaria 7/8 do ETH staked inatingível e, portanto, elegível para ser colocado no mesmo token de staking líquido. Outra opção é criar explicitamente dois níveis de staking: 'risco' (penalizável) staking, que de alguma forma seria limitado a, por exemplo, 1/8 de todo o Ethereum, e 'livre de risco' (não penalizável) staking, no qual todos poderiam participar.

No entanto, uma crítica desta abordagem é que @vbuterin/staking_2023_10?type=view">parece economicamente equivalente a algo muito mais simples: reduzir massivamente a emissão se o stake se aproximar de um limite pré-determinado. O argumento básico é: se acabarmos num mundo onde a camada de suporte ao risco tem retornos de 3,4% e a camada sem risco (na qual todos participam) tem retornos de 2,6%, isso é na verdade o mesmo que um mundo onde o staking de ETH tem retornos de 0,8% e apenas deter ETH não tem retornos. A dinâmica da camada de suporte ao risco, incluindo tanto a quantidade total stakeada quanto a centralização, seria a mesma em ambos os casos. E assim, devemos apenas fazer a coisa simples e reduzir a emissão.

O principal contra-argumento a esta linha de argumentação seria se podemos fazer com que a "camada livre de risco" ainda tenha algum papel útil e algum nível de risco (por exemplo, como proposto por Dankrad aqui).

Ambas estas linhas de propostas implicam alterar a curva de emissão, de forma a tornar os retornos proibitivamente baixos se a quantidade de participação ficar muito alta.

Esquerda: uma proposta para uma curva de emissão ajustada, por Justin Drake. Direita: outro conjunto de propostas, por Anders Elowsson.

Por outro lado, a participação em dois níveis requer a definição de duas curvas de retorno: (i) a taxa de retorno para a participação “básica” (sem risco ou de baixo risco) e (ii) o prémio para a participação com risco. Existem diferentes formas de definir estes parâmetros: por exemplo, se definir um parâmetro rígido de que 1/8 da participação é passível de penalização, então a dinâmica do mercado determinará o prémio na taxa de retorno que a participação passível de penalização recebe.

Outro tópico importante aqui é a captura de MEV. Hoje, a receita do MEV (por exemplo, arbitragem de DEX, sanduíche ...) vai para os proponentes, ou seja, stakers. Esta é uma receita completamente “opaca” para o protocolo: o protocolo não tem forma de saber se é 0,01% APR, 1% APR ou 20% APR. A existência desta fonte de receita é altamente inconveniente em vários aspectos:

1. É uma fonte de receita volátil, pois cada apostador individual só a recebe quando propõe um bloco, o que acontece apenas uma vez a cada ~4 meses atualmente. Isso cria um incentivo para se juntar a pools para obter uma renda mais estável.
2. Isso leva a uma alocação desequilibrada de incentivos: muito para propor, pouco para atestar.
3. Torna-se muito difícil implementar o limite de participação: mesmo que a taxa de retorno "oficial" seja zero, a receita do MEV sozinha pode ser suficiente para levar todos os detentores de ETH a participar. Como resultado, uma proposta realista de limite de participação teria, de fato, que ter retornos próximos do infinito negativo, como por exemplo.@vbuterinproposto aqui. Isso, obviamente, cria mais risco para os apostadores, especialmente para os apostadores individuais.

Podemos resolver esses problemas encontrando uma maneira de tornar a receita MEV legível para o protocolo e capturá-la. A proposta mais antiga foiSuavização de MEV de Francesco; hoje, é amplamente entendido que qualquer mecanismo para leiloar os direitos de proposta de bloco (ou, mais geralmente, autoridade suficiente para capturar quase todo o MEV) antecipadamente alcança o mesmo objetivo.

Quais são alguns links para pesquisas existentes?

• Emissão.wtf: https://issuance.wtf/
• Economia de staking do Endgame, um caso para direcionar:https://ethresear.ch/t/endgame-staking-economics-a-case-for-targeting/18751
• Propriedades do nível de emissão, Anders Elowsson:https://ethresear.ch/t/propriedades-de-incentivos-de-consenso-de-n%C3%ADvel-de-emiss%C3%A3o-e-variabilidade-entre-curvas-de-recompensa-potenciais/18448
• Limite de tamanho do conjunto de validadores: @vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits"">https://notes.ethereum.org/@vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits
• Pensamentos sobre ideias de staking em vários níveis:@vbuterin/staking_2023_10?type=view"">https://notes.ethereum.org/@vbuterin/staking_2023_10?type=view
• Staking do arco-íris:https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
• A proposta de staking líquido de Dankrad: https://notes.ethereum.org/Pcq3m8B8TuWnEsuhKwCsFg
• Suavização de MEV, por Francesco:https://ethresear.ch/t/committee-driven-mev-smoothing/10408
• Queima de MEV, por Justin Drake:https://ethresear.ch/t/mev-burn-a-simple-design/15590

O que resta a fazer e quais são os compromissos?

A principal tarefa restante é concordar em não fazer nada e aceitar os riscos de quase todo o ETH estar dentro dos LSTs, ou finalizar e concordar com os detalhes e parâmetros de uma das propostas acima. Um resumo aproximado dos benefícios e riscos é:

Como interage com outras partes do roteiro?

Um ponto importante de interseção tem a ver com o solo staking. Hoje, os VPS mais baratos que podem executar um nó Ethereum custam cerca de $60 por mês, principalmente devido aos custos de armazenamento em disco rígido. Para um staker de 32 ETH ($84,000 no momento da escrita), isso diminui o APY em (60 * 12) / 84000 ~= 0.85%. Se o retorno total do staking cair abaixo de 0.85%, o solo staking será inviável para muitas pessoas nesses níveis.

Se quisermos que o staking solo continue a ser viável, isso coloca ainda mais ênfase na necessidade de reduzir os custos de operação do nó, o que será feito no Verge: o estado de não armazenamento removerá os requisitos de espaço de armazenamento, o que pode ser suficiente por si só, e depois as provas de validade do L1 EVM tornarão os custos completamente triviais.

Por outro lado, a queima de MEV ajuda, sem dúvida, o solo staking. Embora diminua os retornos para todos, diminui mais importante a variância, tornando o staking menos semelhante a uma loteria.

Finalmente, qualquer alteração na emissão interage com outras alterações fundamentais no design de stake (por exemplo, stake em arco-íris). Um ponto particular de preocupação é que, se os retornos do stake se tornarem muito baixos, isso significa que temos que escolher entre (i) tornar as penalidades também baixas, reduzindo os desincentivos contra comportamentos ruins, e (ii) manter as penalidades altas, o que aumentaria o conjunto de circunstâncias em que até mesmo validadores bem-intencionados acabam acidentalmente com retornos negativos se tiverem azar com problemas técnicos ou mesmo ataques.

Soluções de camada de aplicação

As seções acima focaram nas alterações ao L1 do Ethereum que podem resolver importantes riscos de centralização. No entanto, Ethereum não é apenas um L1, é um ecossistema, e existem também estratégias importantes de camada de aplicação que podem ajudar a mitigar os riscos acima mencionados. Alguns exemplos incluem:

• Soluções especializadas de hardware de staking - algumas empresas, como Dappnode, estão vendendo hardware que foi especificamente projetado para tornar o funcionamento de um nó de stake o mais fácil possível. Uma maneira de tornar essa solução mais eficaz é fazer a pergunta: se um usuário já está se esforçando para ter uma caixa em execução e conectada à internet 24/7, que outros serviços ele poderia fornecer (para o usuário ou para outros) que se beneficiariam da descentralização? Exemplos que vêm à mente incluem (i) executar LLMs hospedados localmente, por motivos de autossuficiência e privacidade, e (ii) executar nós para uma VPN descentralizada.
• Apostas em equipa - isto solução da Obolpermite que várias pessoas apostem juntas em um formato M-de-N. Isso provavelmente se tornará cada vez mais popular com o tempo, à medida que a falta de estado e mais tarde as provas de validade L1 EVM reduzirão o custo de executar mais nós e o benefício de cada participante individual precisar se preocupar muito menos em estar online o tempo todo começa a dominar. Esta é outra maneira de reduzir a sobrecarga cognitiva do apostador e garantir que o apostador individual prospere no futuro.
• Airdrops - Starknet deu um airdrop para apostadores individuais. Outros projetos que desejam ter um conjunto descentralizado e alinhado com os valores de usuários também podem considerar oferecer airdrops ou descontos aos validadores que são identificados como provavelmente sendo apostadores individuais.
• Mercados descentralizados de construção de blocos - usando uma combinação de ZK, MPC e TEEs, é possível criar um construtor de blocos descentralizado que participa e vence o jogo de leilão APS, mas ao mesmo tempo fornece garantias de privacidade pré-confirmação e resistência à censura aos seus usuários. Este é outro caminho para melhorar o bem-estar dos usuários em um mundo APS.
• Minimização de MEV da camada de aplicação - aplicações individuais podem ser construídas de uma forma que "vaza" menos MEV para L1, reduzindo o incentivo para os construtores de blocos criarem algoritmos especializados para coletá-lo. Uma estratégia simples que é universal, embora inconveniente e quebra de composição, é que o contrato coloque todas as operações de entrada em uma fila e as execute no próximo bloco, e leiloe o direito de pular a fila. Outras abordagens mais sofisticadas incluem fazer mais trabalho offchain, por exemplo. como Cowswapdoes. Oracles também podem ser redesenhados para minimizarvalor extraível por oráculo.

Aviso Legal:

1. Este artigo é reproduzido a partir de [ Vitalik Buterin], Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: as opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Learn da gate. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.