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 dominando e pequenos participantes saindo 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, também existem riscos de extração de valor: um pequeno grupo capturando valor que, caso contrário, iria para os usuários do Ethereum.

Nos últimos anos, nossa compreensão desses riscos aumentou consideravelmente. É bem compreendido que existem dois lugares-chave onde esse risco existe: (i) construção de blocos e (ii) provisão de capital para staking. Atuantes maiores podem se dar ao luxo de executar algoritmos mais sofisticados (Extração de Valor de Máxima Eficiência - “MEV”) para gerar blocos, proporcionando a eles uma receita maior por bloco. Atuantes muito grandes também podem lidar de forma mais eficaz com o inconveniente de ter seu capital bloqueado, liberando-o para outros como um token de staking líquido (LST). Além das questões diretas de stakers pequenos versus grandes, também há a questão de se há ou não (ou haverá) muito ETH apostado.

O Flagelo, roteiro de 2023

Este ano, houve avanços significativos na construção de blocos, principalmente a convergência nas “listas de inclusão de comitês mais algumas soluções direcionadas para a ordenação” 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 apostado.

O Flagelo: objetivos-chave

• Minimizar os riscos de centralização na camada de staking do Ethereum (notavelmente, na construção de blocos e provisão de capital, ou seja, MEV e pools de staking)
• Minimizar os riscos de extração excessiva de valor dos usuários

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 fluxo de construção de blocos

Qual problema estamos resolvendo?

Hoje, a construção de blocos do Ethereum é amplamente feita através da separação extra-protocolo do construtor propser comMEVBoost. Quando 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 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 de gadgets financeiros on-chain e transações de usuários que interagem com eles (isso é o que é chamado de “extração de MEV”). Os validadores ficam com a tarefa relativamente leve de economias de escala de “tubo burro” de ouvir lances e aceitar o lance mais alto, bem como outras responsabilidades como atestar.

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

Existem várias versões disso, incluindo “separação entre proponente e construtorOs termos “(PBS)” e “Separação de Attesters-Proposers (APS)” são diferentes em relação aos detalhes minuciosos sobre quais responsabilidades são atribuídas a cada um dos dois atores: em PBS, os validadores ainda propõem blocos, mas recebem o conteúdo do construtor, enquanto em APS, todo o slot se torna responsabilidade do construtor. Recentemente, a APS é preferida em relação à PBS, pois reduz ainda mais os incentivos para que os proposers se localizem junto aos builders. Note que a APS se aplica apenas aos blocos de execução, que contêm transações; os blocos de consenso, que contêm dados relacionados à proof-of-stake, como atestações, ainda serão atribuídos aleatoriamente aos validadores.

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

Dois atores estão escolhendo o conteúdo de aproximadamente 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 são capazes de reorganizar blocos, e portanto você não precisa de 51% de censura para evitar 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 até cinco minutos para certas transações é aceitável. 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 representa 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 usuários. Um "ataque sandwich“ poderia fazer com que os usuários que fazem trocas de tokens sofram perdas significativas devido ao deslizamento. As transações introduzidas para realizar esses ataques entopem a cadeia, aumentando os preços do gás para outros usuários.

O que é isso e como funciona?

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

No momento T, um validador selecionado aleatoriamente cria uma lista de inclusão, uma lista de transações que são válidas de acordo com o estado atual do blockchain naquele momento. No momento T+1, um construtor de bloco, talvez escolhido por meio de um mecanismo de leilão em protocolo antecipadamente, cria um bloco. Este bloco deve incluir todas as transações na lista de inclusão, mas eles podem escolher a ordem e podem adicionar suas próprias transações.

Propostas de listas de inclusão forçada de escolha de fork (FOCIL) envolvem um comitê de vários criadores de lista de inclusão por bloco. Para atrasar uma transação por um bloco, k de k criadores de 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 múltiplos proponentes concorrentes (MCP) como BRAID. BRAID procura evitar dividir o 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 forma que cada proponente só precisa ter uma quantidade média de sofisticação para maximizar sua receita. O MCP funciona tendo k proponentes paralelos gerarem listas de transações e, em seguida, usando um algoritmo determinístico (por exemplo, ordem de taxa mais alta para mais baixa) para escolher a ordem.

A BRAID não busca atingir o objetivo de que os proponentes de blocos burros que executam software padrão sejam ideais. Duas razões fáceis de entender pelas quais ele não pode fazer isso são:

1. Ataques de arbitragem do último a mover: suponha que o tempo médio que os proponentes enviam seja T, e o último momento possível para enviar e ainda ser incluído seja por volta de T+1. Agora, suponha que em exchanges centralizadas, o preço de ETH/USDC muda de $2500 para $2502 entre T e T+1. Um proponente pode esperar um segundo extra e adicionar uma transação adicional para arbitrar em exchanges descentralizadas on-chain, reivindicando até $2 por ETH de lucro. Proponentes sofisticados que estão muito bem conectados à rede têm mais capacidade de fazer isso.
2. Fluxo de ordens 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. Os proponentes sofisticados têm uma vantagem porque podem configurar infraestrutura para aceitar essas transações diretas dos usuários e têm reputações mais fortes, de modo que os usuários que lhes enviam transações podem confiar que o proponente não irá traí-los e front-run (isso pode ser mitigado com hardware confiável, mas o hardware confiável possui pressuposições de confiança próprias)

Em BRAID, os atestadores ainda podem ser separados e executados como uma funcionalidade de tubulação burra.

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

Mempools criptografados

Uma tecnologia que é crucial para a implementação bem-sucedida de muitos desses designs (especificamente, seja BRAID ou uma versão de APS onde existem limites estritos sobre a capacidade sendo leiloada) são mempools criptografados. Mempools criptografados são uma tecnologia onde os usuários transmitem suas transações em forma criptografada, juntamente com algum tipo de prova de sua validade, e as transações são incluídas em blocos em forma criptografada, sem o construtor de blocos conhecer 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 todas 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 de 'último movimento' em um bloco que poderia ser explorado. As duas principais técnicas para isso são (i) descriptografia de limiar, e (ii) atraso de criptografia, um primitivo intimamente relacionado afunções de atraso verificáveis (VDFs).

Quais são alguns links para pesquisas existentes?

• Explicação 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
• Enshrined PBS (uma solução proposta anteriormente para esses problemas): https://ethresear.ch/t/por-que-enshrine-proposer-builder-separation-um-caminho-viável-para-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 o que você precisa”, por Dan Robinson:https://www.paradigm.xyz/2024/06/priority-is-all-you-need
• Em gadgets e protocolos multi-proponentes: https://hackmd.io/xz1UyksETR-pCsazePMAjw
• VDFresearch.org: https://vdfresearch.org/
• Funções de atraso verificáveis e ataques (focado na configuração do RANDAO, mas também aplicável a mempools criptografados):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 na APS: https://arxiv.org/abs/2408.03116
• Multi-block MEV e listas de inclusão: https://x.com/%5fcharlienoyes/status/1806186662327689441

O que resta a fazer e quais são as compensações?

Podemos pensar em todos os esquemas acima como sendo diferentes maneiras de dividir a autoridade envolvida no staking, dispostas em um espectro de economias de escala menores ('dumb-pipe') a economias de escala maiores ('especialização-friendly'). Antes de 2021, todas essas autoridades eram agrupadas em um único ator:

O núcleo do dilema é o seguinte: qualquer autoridade significativa que permaneça nas mãos dos stakers é uma autoridade que pode acabar sendo 'MEV-relevante'. Queremos que um conjunto altamente descentralizado de atores tenha o máximo de autoridade possível; isso implica (i) conferir muita autoridade aos 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. Essa é uma tensão difícil de navegar.

Um desafio particular é o MEV multi-bloco: em alguns casos, os vencedores do leilão de execução podem ganhar ainda mais dinheiro se capturarem múltiplos slots seguidos e não permitirem quaisquer transações relevantes para MEV em blocos além do último que controlam. Se as listas de inclusão os forçarem a isso, eles podem tentar contornar isso não publicando nenhum bloco durante esses slots. Poderia-se criar listas de inclusão incondicionais, que se tornam diretamente o bloco se o construtor não fornecer um, mas isso torna a lista de inclusão relevante para o MEV. A solução aqui pode envolver algum compromisso que envolva aceitar um 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 stakers continuam tendo autoridade na parte esquerda do espectro, enquanto a parte direita do espectro é leiloada para o licitante de maior valor.

BRAID é bastante diferente. A parte 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 via mercado de taxas, em um esquema que pode ser visto como análogo aenshrined PBS.

Observe que a segurança do BRAID depende muito de mempools criptografados; caso contrário, o mecanismo de leilão do topo do bloco se torna vulnerável a ataques de roubo de estratégia (basicamente: copiar 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 o PBS consagrado é tão complicado de implementar.

Finalmente, as versões mais "agressivas" de FOCIL + APS, por exemplo, a opção onde APS apenas determina o final do bloco, parecem 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 uma compreensão dos objetivos da comunidade Ethereum em termos de quais formas de centralização ela tolerará. Também há 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 ideal para APS.

Além disso, vale ressaltar que essas diferentes propostas não são necessariamente bifurcações incompatíveis no caminho um do outro. Por exemplo, implementar FOCIL + APS poderia facilmente servir como um trampolim para implementar 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 validadores é limitada e a maior parte da autoridade é leiloada, e depois aumentamos lentamente a autoridade dos validadores ao longo do tempo, à medida que aprendemos mais sobre o funcionamento do mercado de MEV na rede ao vivo.

Como isso interage com outras partes do roteiro?

Existem interações positivas entre a resolução de um gargalo de centralização de staking e a resolução dos outros. Para dar uma analogia, imagine um mundo onde começar sua própria empresa exigisse cultivar sua própria comida, fazer 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 alguma.

Em particular, os gargalos de centralização para apostar são:

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

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

Além disso, há 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 funções para atestadores em várias etapas do processo. Por esse motivo, vale a pena pensar nos pipelines de construção de blocos e na finalidade de slot único simultaneamente.

Corrigindo a economia de staking

Qual problema estamos resolvendo?

Hoje, cerca de 30% do fornecimento de ETH está apostando ativamente. Isso é muito mais do que suficiente para proteger o Ethereum de ataques de 51%. Se a porcentagem de ETH apostada crescer muito mais, os pesquisadores temem um cenário diferente: os riscos que surgiriam se quase todos os ETH se tornassem apostados. Esses riscos incluem:

• O processo de staking deixa de ser uma tarefa lucrativa para especialistas e se torna uma obrigação 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 para qualquer operador centralizado que ofereça a maior conveniência)
• A credibilidade do mecanismo de redução enfraquece se quase todo o ETH for apostado
• Um único token de staking líquido poderia assumir a maior parte da participação e até mesmo assumir os efeitos de rede de 'dinheiro' do próprio ETH
• Ethereum emite desnecessariamente cerca de ~1 milhão de ETH/ano. No caso em que um token de staking líquido obtém efeito de rede dominante, uma grande parte desse valor poderia potencialmente ser capturada pelo LST.

O que é isso e como funciona?

Historicamente, uma classe de solução tem sido: se todos os stakings são inevitáveis e um token de staking líquido é inevitável, então vamos tornar o staking favorável a 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 a, por exemplo, 1/8, o que tornaria 7/8 do ETH stakado imune a penalidades, e assim elegível para ser colocado no mesmo token de staking líquido. Outra opção é criar explicitamente duas camadas de staking"risco de suportar" (passível de punição) staking, que de alguma forma seria limitado a, por exemplo, 1/8 de todo o ETH, e "livre de risco" (imune a punições) staking, no qual todos poderiam participar.

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

O principal contra-argumento a essa linha de argumentação seria se pudéssemos fazer com que a 'camada sem risco' ainda tivesse algum papel útil e algum nível de risco (por exemplo, como proposto por Dankrad aqui).

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

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

A estaca em duas camadas, por outro lado, requer a definição de duas curvas de retorno: (i) a taxa de retorno para a estaca "básica" (sem risco ou de baixo risco) e (ii) o prêmio para a estaca de suporte de risco. Existem diferentes maneiras de definir esses parâmetros: por exemplo, se você definir um parâmetro rígido em que 1/8 da estaca é passível de penalização, então a dinâmica do mercado determinará o prêmio sobre a taxa de retorno que a estaca passível de penalização recebe.

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

1. É uma fonte de receita volátil, pois cada validador individual só a recebe quando propõe um bloco, o que acontece apenas uma vez a cada ~4 meses hoje. Isso cria um incentivo para participar de 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. Isso torna a limitação de participação muito difícil de implementar: mesmo que a taxa de retorno 'oficial' seja zero, a receita de MEV por si só pode ser suficiente para levar todos os detentores de ETH a participar. Como resultado, uma proposta realista de limitação de participação teria que ter retornos próximos ao infinito negativo, como por exemplo. @vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits">proposed here. This, needless to say, creates more risk for stakers, especially solo stakers.

Podemos resolver esses problemas encontrando uma maneira de tornar a receita de MEV legível para o protocolo e capturá-la. A proposta mais antiga foi Suavização de MEV de Francesco; hoje em dia, é amplamente entendido que qualquer mecanismo para leiloar os direitos de proponente 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?

• Issuance.wtf: https://issuance.wtf/
• Economia de stake do Endgame, um caso para segmentação:https://ethresear.ch/t/endgame-staking-economics-a-case-for-targeting/18751
• Propriedades de nível de emissão, Anders Elowsson:https://ethresear.ch/t/propriedades-do-n%C3%ADvel-de-emiss%C3%A3o-incentivos-de-consenso-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
• Rainbow staking: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
• 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 fazer e quais são os tradeoffs?

A principal tarefa restante é concordar em não fazer nada e aceitar os riscos de quase todo o ETH estar dentro de 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 ela interage com outras partes do roteiro?

Um ponto importante de intersecçã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 de disco rígido. Para um staker de 32 ETH ($84.000 no momento desta escrita), isso diminui o APY em (60 * 12) / 84000 ~= 0,85%. Se os retornos totais do staking caírem 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: a falta de estado 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 indiscutivelmente o solo staking. Embora diminua os retornos para todos, diminui ainda mais a variância, tornando o staking menos parecido com uma loteria.

Finalmente, qualquer mudança na emissão interage com outras mudanças fundamentais no design de staking (por exemplo, staking arco-íris). Um ponto particular de preocupação é que se os retornos do staking 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é validadores bem intencionados acabam acidentalmente com retornos negativos se tiverem azar com problemas técnicos ou até mesmo ataques.

Soluções de camada de aplicação

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

• Soluções especializadas de hardware de staking - algumas empresas, como Dappnode, estão vendendo hardware que é especificamente projetado para tornar o funcionamento de um nó de staking 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 manter um dispositivo em funcionamento e conectado à internet 24 horas por dia, 7 dias por semana, que outros serviços poderiam ser fornecidos (para o usuário ou para outros) que se beneficiem da descentralização? Exemplos que vêm à mente incluem (i) executar LLMs hospedados localmente, por razões de autossuficiência e privacidade, e (ii) executar nós para uma VPN descentralizada.
• Staking em grupo - issosolução da Obolpermite que várias pessoas apostem juntas em um formato M-de-N. Isso provavelmente se tornará cada vez mais popular ao longo do tempo, à medida que a falta de estado e mais tarde as provas de validade do EVM L1 reduzirão a sobrecarga 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 staking e garantir que o staking solo prospere no futuro.
• Airdrops - Starknet deu umairdrop para stakers individuais. Outros projetos que desejam ter um conjunto descentralizado e alinhado com valores de usuários também podem considerar dar airdrops ou descontos aos validadores que são identificados como provavelmente sendo apostadores solitários.
• 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 oferece privacidade prévia e garantias de resistência à censura aos seus usuários. Este é outro caminho para melhorar o bem-estar dos usuários em um mundo APS.
• Minimização do MEV da camada de aplicação - aplicações individuais podem ser construídas de forma a "vazar" menos MEV para L1, reduzindo o incentivo para os construtores de blocos criarem algoritmos especializados para coletá-lo. Uma estratégia simples e universal, embora inconveniente e quebradora de composição, é fazer com que o contrato coloque todas as operações de entrada em uma fila e as execute no próximo bloco, leiloando o direito de pular a fila. Outras abordagens mais sofisticadas incluem fazer mais trabalho offchain, por exemplo, como Cowswapfaz. Os oráculos também podem ser redesenhados para minimizarvalor extraível do oráculo.

Aviso Legal：

1. Este artigo foi republicado de [Vitalik Buterin], Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, por favor, entre em contato com o Aprender no Gateequipe e eles vão cuidar disso 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 de aprendizado do gate. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.