O processo de resolução do problema do MEV é, na verdade, reformular as regras de alocação de espaço do Bloco. Para MEV, acredito que você não está mais familiarizado com isso, mas se você quiser saber do que algumas propostas de governança ETH MEV estão falando, você ainda pode precisar de algumas informações básicas, portanto, este artigo vasculha uma série de propostas sobre governança MEV, como PBS, ePBS e PEPC desde que a ETH Square se voltou para PoS, na esperança de fornecer algumas informações básicas.
PBS(Proposer Builder Seperatioin)
Antes da Fusão de ETH, a forma de resolver o MEV era através do MEV-Geth desenvolvido pela Flashbots, que é um cliente go-ethereum modificado. A ideia principal é permitir que os mineiros se concentrem em seu trabalho principal, a mineração, em vez de participar da disputa do MEV, evitando assim possíveis problemas de reorganização. O mecanismo do MEV-Geth é simples e baseado em um sistema de mercado, onde os mineiros selecionam as transações com base nos lucros dos pacotes enviados pelos searchers. Por meio desse engenhoso mecanismo de mercado, as partes envolvidas obtêm benefícios e também estabelecem algumas restrições. Embora os searchers precisem compartilhar parte dos lucros com os mineiros, em troca obtêm a garantia de que seus resultados não serão roubados pelos mineiros. Quando a principal fonte de lucro dos searchers é cercada, os mineiros começam a utilizar o MEV-Geth de forma passiva e são ainda mais restritos pelo mecanismo do MEV-Geth. O MEV-Geth mantém uma lista de permissões dos mineiros, onde apenas os mineiros autorizados podem receber os pacotes dos searchers. Ao impor restrições de crédito aos mineiros e remover aqueles que roubam os resultados dos searchers da lista de permissões, é possível evitar que os mineiros roubem os lucros do MEV dos searchers.
Mas após a fusão, devido à mudança na forma de geração de Bloco, que agora é proposto aleatoriamente pelos validadores, o método de restrição de reputação para impedir que o proposer roube a MEV não é mais viável.
Uma solução possível é tornar o conteúdo do Bloco invisível para os validadores. Seguindo essa ideia, aperfeiçoando-a ainda mais, temos o PBS (Proposer Builder Seperation, Separação de Construtor de Proposta). O PBS decompõe ainda mais a responsabilidade dos validadores como proponente para construção e proposta de Bloco, terceirizando o direito de construção que pode ser objeto de disputa de interesses para o construtor. Assim, o trabalho do proponente se torna simples, escolhendo o Bloco a ser proposto com base no tamanho do lucro submetido pelo construtor.
Inicialmente, o Ethereum queria incorporar o PBS no protocolo durante a fusão, mas devido à complexidade potencial, esse processo foi adiado, dando assim a oportunidade para o MEV-Boost se envolver no PBS. Atualmente, o PBS é implementado através do MEV-Boost desenvolvido pela Flashbots. Além do construtor e do proponente, há também um papel muito importante - o relay. O construtor não envia diretamente o bloco para o proponente, mas sim através de um terceiro papel, o relay.
Porque ainda há outros problemas a resolver, como garantir que o construtor pague sempre as taxas ao propositor e divulgue sempre o conteúdo do bloco para evitar que o propositor seja punido por enviar um bloco vazio; como garantir que o bloco enviado pelo construtor seja sempre incluído na cadeia beacon, etc. Essas questões que protegem os interesses do construtor e do propositor são principalmente implementadas através de relés.
O construtor envia o Bloco para o relé, que classifica o Bloco com base no lucro que cada Bloco pode obter e, em seguida, envia a cabeça do Bloco com o maior lucro para o proponente, a fim de garantir que o proponente não possa ver o conteúdo do Bloco. Somente após o proponente comprometer-se com a proposta do Bloco (assinando a cabeça do Bloco) é que o relé divulgará o Bloco completo ao proponente. O pagamento da taxa pelo construtor ao proponente também deve ser concluído por meio do relé para garantir a conclusão. A transação paga ao proponente é incluída no Bloco enviado, mas como o proponente não pode ver o conteúdo do Bloco, ainda precisa ser confirmada antecipadamente pelo relé.
No protocolo & protocolo de saída
Para participar no mercado construído pelo MEV-Boost, os validadores precisam executar o cliente Consenso Ethereum e executar um programa MEV-Boost de terceiros que não seja do Ethereum ao mesmo tempo. E é aqui que o PBS em execução atualmente é incrível, pois permite que terceiros fora do protocolo participem do design das regras formadas pelo Consenso Ethereum. Do ponto de vista da propriedade, isso é surpreendente.
Isso também levanta questões sobre a ‘credibilidade’ do protocolo, como ela é reforçada e como pode ser erodida por outros mecanismos. O MEV-Boost é um bom exemplo disso, pois pode haver casos em que um protocolo externo possa alterar os mecanismos existentes. Quando o próprio protocolo começa a ficar desatualizado, essas alterações podem surgir externamente. O surgimento de mecanismos externos certamente atenderá às demandas atuais do mercado, mas ainda não sabemos se esses mecanismos externos são confiáveis, se foram projetados minuciosamente para evitar problemas potenciais e se podem até mesmo prejudicar o próprio protocolo.
Relé centralizado
O MEV-Boost é mais criticado pelo mercado de relés centralizado. No entanto, essa configuração introduz um problema de confiança. Os construtores precisam confiar que os relés não irão roubar seus MEV. Os proponentes também devem confiar que os cabeçalhos de bloco recebidos e assinados pelos relés são válidos. No entanto, apesar de desempenhar um papel crucial, os relés não possuem nenhum incentivo econômico e executar um relé também requer um investimento significativo. No ano passado, havia 11 relés que suportavam a rede Ethereum, mas hoje apenas 9 ainda estão em serviço.
É importante notar que o relay não é sem restrições, como o Eden, um relay como o Relé tem apenas seu próprio builder. Alguns relays, como o bloXroute, afirmam filtrar transações relacionadas a front-running e ataques de sanduíche. Em certa medida, o relay também possui certa autonomia na definição de regras.
Os dados são provenientes da Rede Classificada
Além disso, do ponto de vista da Liveness, devido à existência do relay, o builder e o proposer não podem fornecer confirmação em nível atômico. Se o proposer assinar o compromisso no cabeçalho do bloco e o builder fornecer o conteúdo da carga útil, mas devido a um erro no relay (seja malicioso ou não), o conteúdo não puder ser enviado a tempo, o builder e o proposer incorrerão em perdas.
ePBS: Embalando o PBS no Ethereum
Seja para resolver o problema da centralização do relay ou para mover a parte externa ao protocolo para dentro do protocolo, parece ser uma opção necessária encapsular o PBS no éter do ETH. Atualmente, o ePBS não é mais uma proposta em discussão, a edição do EIP do ETH já o atribuiu um número - EIP-7732.
O ePBS fornece uma infraestrutura confiável para os proponentes e construtores terceirizarem a construção de blocos. O papel do construtor, que originalmente estava fora do protocolo, foi incorporado ao protocolo, onde foi separado em uma função de construtor dentro dos validadores. O construtor dos validadores também precisa fazer stake na rede Ethereum. Como as responsabilidades do proponente foram separadas na camada de Consenso, é necessário modificar a camada de Consenso para concluir o ePBS. O construtor é responsável pela construção da carga útil de execução (a lista final de transações a serem executadas nesse bloco). O proponente é responsável por propor o bloco de referência. O processo específico é o seguinte:
Após ser selecionado como Proposer, faça e transmita a Lista de Inclusão (IL, ou seja, as transações que devem estar incluídas neste slot).
Os construtores enviam ao proposer o Blocohash que contém a carga útil de hash, bem como o compromisso de pagar a taxa ao proposer ‘SignedutionPayloadHeader’ (a carga útil deve atender ao IL).
O proponente seleciona um ‘SignedutionPayloadHeader’ dos construtores e o inclui (geralmente escolhendo o de preço mais alto para o proponente). E difunde o bloco de sinalização proposto ‘SignedBeaconBlock’.
Os testemunhos cumprem o seu dever de testemunhar
os agregadores enviam agregados de atestação; entretanto, o construtor difunde a carga útil de ution
O PTC (Comitê de Pontualidade de Carga, em cada slot, 512 validadores serão selecionados como membros do PTC) verifica se o construtor revela payload de execução a tempo e transmite o resultado
ePBS passou por várias discussões desde sua concepção até a obtenção do número EIP. Inicialmente proposto por Vitalik em junho de 21, o esquema Two-slot foi aprimorado quatro meses depois, seguido pela proposta Single-slot PBS três meses depois. Somente em julho de 23, a ideia da PTC foi formalmente apresentada.
PEPC (Compromissos de Propositores Aplicados por Protocolo)
Claro, também há discordâncias em relação ao ePBS, com a esperança de substituí-lo por outras soluções. O PEPC é um exemplo disso. Enquanto o ePBS incorpora regras específicas no protocolo, no caso do PEPC, o proponente vende o direito de construção de Blocos com Programabilidade.
PEPC foi proposto por barnabe em outubro de 2022. barnabe acredita que, se o mecanismo PBS for implementado no protocolo, deve-se considerar a implementação de um mecanismo genérico para a transmissão de sinais confiáveis, em vez de implementar um mecanismo específico para sinais confiáveis (por exemplo, se me pedirem para construir um Bloco, eu devolveria xx ETH para você).
Assim como o nome PEPC (Protocol-Enforced Proposer Commitments), alguns mecanismos que garantem os direitos do construtor e do proponente são realizados através do compromisso apresentado pelo proponente no protocolo, esses compromissos podem ser verificados na cadeia, principalmente realizados pelo Código de operação “BEACONROOT”. Este é um mecanismo mais genérico, o compromisso pode ser terceirizado completamente para a construção do Bloco, ou apenas parcialmente, ou seja, o proponente está vendendo o direito de construção do Bloco com Programabilidade.
Conclusão
Aqui está uma breve introdução ao PBS, ePBS e PEPC. Do ponto de vista do protocolo, não só é necessário projetar um mecanismo de mercado para redistribuir o MEV, mas também considerar como tornar os validadores mais descentralizados e como aumentar a resistência à censura. Além disso, o design do protocolo também envolve muitos compromissos. Tomemos o ePBS, que já recebeu o número de EIP, como exemplo. Embora o design do ePBS resolva o problema centralizado do relay, será que a eliminação do papel crucial do relay de terceiros fora do protocolo terá apenas impactos negativos? Em termos de mecanismo de pagamento do construtor, o uso do relay é realmente mais vantajoso do que o mecanismo ePBS, uma vez que o ePBS é um mecanismo pré-pago. Se um construtor empacotar um bloco com lucros excessivamente altos, não será capaz de oferecer um alto retorno ao proponente sob o mecanismo pré-pago.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Atualmente, o jogo de Consenso Ethereum e MEV, começa com a transição do PoW para o PoS...
Escrito por: Tia, Techub News
O processo de resolução do problema do MEV é, na verdade, reformular as regras de alocação de espaço do Bloco. Para MEV, acredito que você não está mais familiarizado com isso, mas se você quiser saber do que algumas propostas de governança ETH MEV estão falando, você ainda pode precisar de algumas informações básicas, portanto, este artigo vasculha uma série de propostas sobre governança MEV, como PBS, ePBS e PEPC desde que a ETH Square se voltou para PoS, na esperança de fornecer algumas informações básicas.
PBS(Proposer Builder Seperatioin)
Antes da Fusão de ETH, a forma de resolver o MEV era através do MEV-Geth desenvolvido pela Flashbots, que é um cliente go-ethereum modificado. A ideia principal é permitir que os mineiros se concentrem em seu trabalho principal, a mineração, em vez de participar da disputa do MEV, evitando assim possíveis problemas de reorganização. O mecanismo do MEV-Geth é simples e baseado em um sistema de mercado, onde os mineiros selecionam as transações com base nos lucros dos pacotes enviados pelos searchers. Por meio desse engenhoso mecanismo de mercado, as partes envolvidas obtêm benefícios e também estabelecem algumas restrições. Embora os searchers precisem compartilhar parte dos lucros com os mineiros, em troca obtêm a garantia de que seus resultados não serão roubados pelos mineiros. Quando a principal fonte de lucro dos searchers é cercada, os mineiros começam a utilizar o MEV-Geth de forma passiva e são ainda mais restritos pelo mecanismo do MEV-Geth. O MEV-Geth mantém uma lista de permissões dos mineiros, onde apenas os mineiros autorizados podem receber os pacotes dos searchers. Ao impor restrições de crédito aos mineiros e remover aqueles que roubam os resultados dos searchers da lista de permissões, é possível evitar que os mineiros roubem os lucros do MEV dos searchers.
Mas após a fusão, devido à mudança na forma de geração de Bloco, que agora é proposto aleatoriamente pelos validadores, o método de restrição de reputação para impedir que o proposer roube a MEV não é mais viável.
Uma solução possível é tornar o conteúdo do Bloco invisível para os validadores. Seguindo essa ideia, aperfeiçoando-a ainda mais, temos o PBS (Proposer Builder Seperation, Separação de Construtor de Proposta). O PBS decompõe ainda mais a responsabilidade dos validadores como proponente para construção e proposta de Bloco, terceirizando o direito de construção que pode ser objeto de disputa de interesses para o construtor. Assim, o trabalho do proponente se torna simples, escolhendo o Bloco a ser proposto com base no tamanho do lucro submetido pelo construtor.
Inicialmente, o Ethereum queria incorporar o PBS no protocolo durante a fusão, mas devido à complexidade potencial, esse processo foi adiado, dando assim a oportunidade para o MEV-Boost se envolver no PBS. Atualmente, o PBS é implementado através do MEV-Boost desenvolvido pela Flashbots. Além do construtor e do proponente, há também um papel muito importante - o relay. O construtor não envia diretamente o bloco para o proponente, mas sim através de um terceiro papel, o relay.
Porque ainda há outros problemas a resolver, como garantir que o construtor pague sempre as taxas ao propositor e divulgue sempre o conteúdo do bloco para evitar que o propositor seja punido por enviar um bloco vazio; como garantir que o bloco enviado pelo construtor seja sempre incluído na cadeia beacon, etc. Essas questões que protegem os interesses do construtor e do propositor são principalmente implementadas através de relés.
O construtor envia o Bloco para o relé, que classifica o Bloco com base no lucro que cada Bloco pode obter e, em seguida, envia a cabeça do Bloco com o maior lucro para o proponente, a fim de garantir que o proponente não possa ver o conteúdo do Bloco. Somente após o proponente comprometer-se com a proposta do Bloco (assinando a cabeça do Bloco) é que o relé divulgará o Bloco completo ao proponente. O pagamento da taxa pelo construtor ao proponente também deve ser concluído por meio do relé para garantir a conclusão. A transação paga ao proponente é incluída no Bloco enviado, mas como o proponente não pode ver o conteúdo do Bloco, ainda precisa ser confirmada antecipadamente pelo relé.
No protocolo & protocolo de saída
Para participar no mercado construído pelo MEV-Boost, os validadores precisam executar o cliente Consenso Ethereum e executar um programa MEV-Boost de terceiros que não seja do Ethereum ao mesmo tempo. E é aqui que o PBS em execução atualmente é incrível, pois permite que terceiros fora do protocolo participem do design das regras formadas pelo Consenso Ethereum. Do ponto de vista da propriedade, isso é surpreendente.
Isso também levanta questões sobre a ‘credibilidade’ do protocolo, como ela é reforçada e como pode ser erodida por outros mecanismos. O MEV-Boost é um bom exemplo disso, pois pode haver casos em que um protocolo externo possa alterar os mecanismos existentes. Quando o próprio protocolo começa a ficar desatualizado, essas alterações podem surgir externamente. O surgimento de mecanismos externos certamente atenderá às demandas atuais do mercado, mas ainda não sabemos se esses mecanismos externos são confiáveis, se foram projetados minuciosamente para evitar problemas potenciais e se podem até mesmo prejudicar o próprio protocolo.
Relé centralizado
O MEV-Boost é mais criticado pelo mercado de relés centralizado. No entanto, essa configuração introduz um problema de confiança. Os construtores precisam confiar que os relés não irão roubar seus MEV. Os proponentes também devem confiar que os cabeçalhos de bloco recebidos e assinados pelos relés são válidos. No entanto, apesar de desempenhar um papel crucial, os relés não possuem nenhum incentivo econômico e executar um relé também requer um investimento significativo. No ano passado, havia 11 relés que suportavam a rede Ethereum, mas hoje apenas 9 ainda estão em serviço.
É importante notar que o relay não é sem restrições, como o Eden, um relay como o Relé tem apenas seu próprio builder. Alguns relays, como o bloXroute, afirmam filtrar transações relacionadas a front-running e ataques de sanduíche. Em certa medida, o relay também possui certa autonomia na definição de regras.
Os dados são provenientes da Rede Classificada
Além disso, do ponto de vista da Liveness, devido à existência do relay, o builder e o proposer não podem fornecer confirmação em nível atômico. Se o proposer assinar o compromisso no cabeçalho do bloco e o builder fornecer o conteúdo da carga útil, mas devido a um erro no relay (seja malicioso ou não), o conteúdo não puder ser enviado a tempo, o builder e o proposer incorrerão em perdas.
ePBS: Embalando o PBS no Ethereum
Seja para resolver o problema da centralização do relay ou para mover a parte externa ao protocolo para dentro do protocolo, parece ser uma opção necessária encapsular o PBS no éter do ETH. Atualmente, o ePBS não é mais uma proposta em discussão, a edição do EIP do ETH já o atribuiu um número - EIP-7732.
O ePBS fornece uma infraestrutura confiável para os proponentes e construtores terceirizarem a construção de blocos. O papel do construtor, que originalmente estava fora do protocolo, foi incorporado ao protocolo, onde foi separado em uma função de construtor dentro dos validadores. O construtor dos validadores também precisa fazer stake na rede Ethereum. Como as responsabilidades do proponente foram separadas na camada de Consenso, é necessário modificar a camada de Consenso para concluir o ePBS. O construtor é responsável pela construção da carga útil de execução (a lista final de transações a serem executadas nesse bloco). O proponente é responsável por propor o bloco de referência. O processo específico é o seguinte:
ePBS passou por várias discussões desde sua concepção até a obtenção do número EIP. Inicialmente proposto por Vitalik em junho de 21, o esquema Two-slot foi aprimorado quatro meses depois, seguido pela proposta Single-slot PBS três meses depois. Somente em julho de 23, a ideia da PTC foi formalmente apresentada.
PEPC (Compromissos de Propositores Aplicados por Protocolo)
Claro, também há discordâncias em relação ao ePBS, com a esperança de substituí-lo por outras soluções. O PEPC é um exemplo disso. Enquanto o ePBS incorpora regras específicas no protocolo, no caso do PEPC, o proponente vende o direito de construção de Blocos com Programabilidade.
PEPC foi proposto por barnabe em outubro de 2022. barnabe acredita que, se o mecanismo PBS for implementado no protocolo, deve-se considerar a implementação de um mecanismo genérico para a transmissão de sinais confiáveis, em vez de implementar um mecanismo específico para sinais confiáveis (por exemplo, se me pedirem para construir um Bloco, eu devolveria xx ETH para você).
Assim como o nome PEPC (Protocol-Enforced Proposer Commitments), alguns mecanismos que garantem os direitos do construtor e do proponente são realizados através do compromisso apresentado pelo proponente no protocolo, esses compromissos podem ser verificados na cadeia, principalmente realizados pelo Código de operação “BEACONROOT”. Este é um mecanismo mais genérico, o compromisso pode ser terceirizado completamente para a construção do Bloco, ou apenas parcialmente, ou seja, o proponente está vendendo o direito de construção do Bloco com Programabilidade.
Conclusão
Aqui está uma breve introdução ao PBS, ePBS e PEPC. Do ponto de vista do protocolo, não só é necessário projetar um mecanismo de mercado para redistribuir o MEV, mas também considerar como tornar os validadores mais descentralizados e como aumentar a resistência à censura. Além disso, o design do protocolo também envolve muitos compromissos. Tomemos o ePBS, que já recebeu o número de EIP, como exemplo. Embora o design do ePBS resolva o problema centralizado do relay, será que a eliminação do papel crucial do relay de terceiros fora do protocolo terá apenas impactos negativos? Em termos de mecanismo de pagamento do construtor, o uso do relay é realmente mais vantajoso do que o mecanismo ePBS, uma vez que o ePBS é um mecanismo pré-pago. Se um construtor empacotar um bloco com lucros excessivamente altos, não será capaz de oferecer um alto retorno ao proponente sob o mecanismo pré-pago.