Uma forma trivial de PBS: MEV Lock – Consensus

Aprendi essa ideia (se não exatamente a mesma, algo muito parecido) com @JustinDrake.

Resumo

Com o EIP-7732 chegando no fork Gloas, temos novos validadores on-chain com prefixo de retirada específico 0x03 que estão autorizados a produzir cargas úteis e licitar pela sua inclusão. Nesta proposta, descrevo uma maneira muito simples de implementar de separar completamente o papel do construtor do papel do proponente dos validadores. Este mecanismo tem diversas vantagens:

• Ele resolve completamente o problema da (opção gratuita) ((2509.24849) O problema da opção gratuita do ePBS).
• Ele remove qualquer construtor do proponente de comunicação <–> que afete a latência da construção de blocos e do pipeline de slots.
• Isso elimina parte da complexidade da especificação de consenso em torno dos pagamentos dos construtores aos proponentes.
• Tem um efeito positivo na economia do ativo ETH.

O mecanismo

O mecanismo é muito simples, consiste em

1. Remova quaisquer deveres de validação e recompensas/penalidades dos validadores 0x03. Sua aposta só fica trancada na beacon chain sem receber recompensas nem ser penalizada.
2. Remova qualquer limite de aposta dos validadores 0x03, eles podem apostar o quanto quiserem.
3. O protocolo escolhe construtores aleatoriamente, de forma semelhante ao que fazemos agora com os proponentes, apenas a partir de validadores 0x03. Esta escolha é amostrada aleatoriamente, mas ponderada por aposta.
4. Adicione um mecanismo automático à prova de falhas para colocar temporariamente na lista negra alguns construtores 0x03 se eles não conseguirem entregar algumas cargas úteis e, por fim, voltar à autoconstrução se não houver mais construtores 0x03 disponíveis.

Prós

• O problema da opção gratuita desaparece porque não há compromisso do construtor com uma carga útil específica. Existe apenas o prazo na hora da revelação, dos blocos e das bolhas.
• Não há necessidade de o proponente se comprometer com qualquer oferta do construtor, o proponente apenas se compromete com o hash do bloco pai na camada de execução, o construtor precisa construir sobre esse cabeçalho de execução. Dessa forma, o conjunto descentralizado de proponentes mantém as decisões na forkchoice. Os construtores apenas sequenciam a cadeia.
• Não há necessidade de qualquer comunicação entre os proponentes do consenso e os construtores da execução.
• Não há necessidade de nenhum mecanismo de pagamento para pagar uma proposta do construtor ao proponente. O construtor não paga mais a ninguém, seu custo é o custo de capital do staking.
• A receita do MEV passa dos proponentes para ser compartilhada pelos construtores (já que eles não precisam mais pagar propostas) e pelos detentores de ETH (uma vez que o custo da taxa de juros perdida sobre o ETH bloqueado que é pago pelos construtores é, em última análise, compartilhado por todos os detentores de ETH).
• Se o protocolo assim o desejar, podemos até fazer uma forma de queima de MEV cobrando da aposta 0x03 uma taxa constante de acordo com as condições do mercado.

Contras

• Esta é uma força centralizadora na construção de blocos. O FOCIL ou qualquer mecanismo de lista de inclusão forçada é necessário para que este sistema seja implementado.
• Os pools de staking seriam afetados. No entanto, os pools de staking, por definição, têm controle sobre grandes quantidades de ETH. Se a receita MEV perdida com taxas se tornar maior do que o custo de capital de apostar aquela ETH como um validador 0x03, os próprios pools de piquetagem podem ser construtores e potencialmente leiloar seus slots de protocolo.
• O conluio entre um conjunto centralizado de construtores é possível. Em muitos aspectos, por um lado, o MEV de múltiplos slots torna-se mais predominante quando há um conjunto reduzido de construtores. Por outro lado, um pequeno conjunto de construtores pode conspirar para minimizar o seu custo de capital bloqueado. Porém, como o sistema não tem permissão, é racional que os detentores de ETH apostem nesta situação, mitigando ambos os aspectos.

Olá @potuz ! Obrigado por escrever isso. Acho que o mecanismo que você descreve aqui é quase o mesmo dos Tickets de Execução. A diferença é que os potenciais construtores compram ingressos apostando em vez de pagar diretamente pelos ingressos. A “parte de compra” dos dois mecanismos é diferente, mas a forma como os direitos de construção seriam atribuídos é semelhante, por exemplo, usar RANDAO para atribuir direitos de construção aleatoriamente com alguma previsão.

Os tíquetes de execução têm desvantagens conhecidas, que você também aponta.

• O MEV multi-slot torna-se possível porque se sabe de antemão qual construtor construirá o próximo bloco. Se o construtor A souber que constrói dois slots consecutivos, poderá ajustar o conteúdo do primeiro bloco para extrair mais MEV no segundo. O MEV multislot tem externalidades negativas para os usuários e dificulta o design de aplicativos.
• A construção de blocos torna-se mais centralizada, pois os construtores precisam prever o valor do bloco.

O problema fundamental do MEV multi-slot neste projeto é que se sabe de antemão quem constrói os próximos X blocos. No MEV-Boost, os construtores precisam competir novamente em cada slot, para que só se saiba quem constrói o próximo bloco pouco antes de ele precisar ser propagado.

A probabilidade de receber dois slots consecutivos neste design depende da fração da aposta 0x03 que qualquer construtor controla. Penso que não podemos confiar que essa probabilidade seja simplesmente muito baixa. O mercado de construtoras está muito concentrado hoje porque a diferença de rentabilidade entre as principais construtoras e as demais é grande. Se os construtores não conspirarem, eles ainda poderão encontrar oportunidades de MEV multi-slot, no entanto, pode não ser racional para os detentores de ETH apostar, de modo que o MEV multi-slot não seja mitigado.