Parte 1: Como Chegamos Até Aqui

Inicialmente, o Ethereum foi projetado com a ideia de que uma única parte lidaria com todo o processo de criação de bloco. Isso envolvia agregar transações da mempool, criar o cabeçalho do bloco e encontrar o nonce dourado na prova de trabalho ou simplesmente assinar o cabeçalho do bloco na prova de participação. Nos primeiros anos, a construção de blocos era direta: os nós de mineração retiravam transações de sua mempool, as ordenavam com base no preço do gás, que significa o trabalho computacional de cada transação, e permaneciam dentro do limite de gás por bloco. No entanto, com o surgimento das finanças descentralizadas (DeFi), essa abordagem para a construção de blocos passou por mudanças significativas.

A Ameaça de Centralização do MEV

No DeFi, a sequência em que as transações são ordenadas pode fazer uma grande diferença. Digamos que haja uma transação esperando na mempool que visa trocar 1 ETH por BITCOIN (estou falando sobre HarryPotterObamaSonic10Inu, é claro) na UniSwap. A quantidade de BITCOIN que você receberia é baseada na proporção atual de ETH para BITCOIN no pool da UniSwap. Se a transação de outra pessoa, trocando 2 ETH por BITCOIN, for processada imediatamente antes da sua, você acabará com menos BITCOIN porque a proporção de ETH para BITCOIN mudou. Dada a importância da ordem das transações, e os mineradores controlam essa ordem, isso levou ao surgimento do que chamamos de MEV, ou Valor Extraível Máximo do Minerador. MEV representa o lucro potencial que um minerador pode obter escolhendo quais transações incluir, excluir ou rearranjar.

O MEV pode parecer inofensivo no início. Caramba, poderia até aparecer como um impulsionador para a segurança da rede, mais incentivos para mineração ou validação, certo? Além das habituais recompensas em bloco e taxas de transação, agora há MEV em disputa. Mas a realidade está longe de ser inofensiva. Se não for controlada, a MEV pode se tornar uma potente força centralizadora. Aqui está uma história para ilustrar isso: Imagine que você acabou de tomar conhecimento deste jogo MEV e ouvir que os validadores estão arrecadando mais de 10% de APR por causa disso. Tentador, né? Você está dentro! Assim, você envia seus 32 ETH para o contrato de staking e inicia um nó validador. Mas espere um minuto... Você só está vendo um retorno de 4%. Quando chega a sua vez de propor um bloco, as transações simplesmente se alinham pelo preço do gás. Sem magia MEV. Você não está armado com os intrincados algoritmos e táticas para minerar esse ouro MEV. Sem o know-how, você fica preso ao padrão: ordenar transações pelo preço do gás.

Aqui é onde o puxão centralizador entra em ação. Mesmo que você seja um quant, seu computador simples, talvez um raspberry pi, não chega aos pés de seus supercomputadores executando jogadas de extração de MEV de próximo nível. O objetivo óbvio aqui é desligar seu validador e, em vez disso, enviar seu ETH para essas configurações super potentes que prometem uma parte do bolo do MEV. Avance rápido e você pode ver um punhado desses gigantes essencialmente executando a rede, um resultado centralizado verdadeiramente inquietante. Se é para onde as coisas estão indo, então os objetivos fundamentais do Ethereum falharam. Uma rede dominada por alguns poucos poderia muito bem ser um banco de dados centralizado nesse ponto.

O Nascimento dos Flashbots

Phil Daian, um estudante de doutorado em Cornell com especialização em segurança de contratos inteligentes, estava entre os primeiros identificadores do problema de MEV. Em agosto de 2017, ele publicou um blog intitulado "O Custo da Descentralização em 0x e EtherDelta." Esse blog foi inspirado pelas vulnerabilidades de front-running que ele identificou durante a ICO da 0x.

Front-running envolve detectar uma transação no mempool que visa trocar o Token A pelo Token B. Um favorito então inicia programaticamente uma transação semelhante que oferece um preço de gás mais alto. Essa estratégia garante que a transação do favorito seja processada antes da original. Depois que a transação inicial é processada, o favorito pode imediatamente trocar o Token B de volta pelo Token A, terminando com uma quantidade maior de Token A do que começou. Essa tática às vezes é chamada de ataque sanduíche, pois a transação do usuário fica ensanduichada entre duas transações iniciadas pelo favorito. Como resultado, enquanto o favorito ganha lucro, o indivíduo por trás da transação original recebe menos do Token B. Enquanto ataques de sanduíche são comuns, existem várias estratégias que os indivíduos podem usar para extrair MEV de forma eficaz.

Visualizando o Ataque do Sanduíche: Como os Primeiros Lucram à Custa dos Outros

Durante o boom do ICO, Phil e uma equipe implantaram um robô que rendia cerca de um milhão de dólares anualmente. Após compartilhar sua metodologia na postagem do blog que mencionei anteriormente, surgiram vários robôs semelhantes, criando um cenário competitivo onde os robôs superariam os preços de gás uns dos outros para alcançar prioridade de transação. Isso levou Phil a implantar nós globalmente, capturando dados transacionais em tempo real. Essa pesquisa culminou em seu famoso Papel "Flash Boys 2.0", que mergulhou fundo nos desafios do MEV causados pelas exchanges descentralizadas.

Aqui está uma história divertida relacionada que Phil compartilhou quando ele foi um convidado no BerlindaQuando Hayden Adams, o fundador da UniSwap, compartilhou seu design para o que agora é a bolsa descentralizada mais popular em ethresear.ch. Phil imediatamente enviou mensagens com suas preocupações tanto para Vitalik quanto para Hayden. Phil acreditava que o design da UniSwap causaria uma quantidade significativa de MEV, tornando-se um alvo principal para exploração e colocando os usuários em risco de reordenamento de transações e ataques sandwich. Vitalik respondeu sugerindo que isso poderia ser visto apenas como um mecanismo de taxa adicional para usar a blockchain. Phil ficou tão irritado com essa resposta e pensou que entidades financeiras poderosas como o Goldman Sachs iriam entrar e devorar o almoço dos pequenos como no sistema financeiro atual. No entanto, com o tempo, Phil passou a adotar a perspectiva de Vitalik (todo o louvor ao senhor Vitalik).

Reconhecendo a importância e os desafios do espaço MEV, Phil co-fundou Flashbots, uma empresa focada em pesquisa e soluções na arena MEV. Flashbots percebeu que o MEV vai existir e Flashbots é missão de garantir que a existência do MEV não leve a um sistema onde ser uma pessoa má ou criar externalidades negativas seja melhor para você individualmente e seja mais lucrativo do que ser um bom ator. Um exemplo disso está no TradFi, as estratégias mais lucrativas frequentemente envolvem a exploração das margens do sistema. Além disso, Flashbots pensou que poderia haver uma maneira de aproveitar a energia do MEV para os usuários e subsidiar pessoas que seguram a rede e também subsidiar transações na rede para dar às pessoas preços melhores para dar às pessoas a execução que desejam nesses sistemas. Se projetado corretamente, o MEV poderia ser parte do que faz com que as criptomoedas superem os sistemas tradicionais.

Aproveitando o MEV: O Papel de Leilões e Separação de Proprietários-Construtores

O Flashbots reconheceu que o monopólio dos mineradores sobre a ordem das transações era um recurso valioso. Seu primeiro passo para democratizar o MEV envolveu a criação de um sistema de leilão para os direitos de ordem das transações. Isso levou à criação do MEV GETH, que introduziu pela primeira vez o conceito de separação de proponente-construtor (PBS). Barnabé Monnot, da Ethereum Foundation, descreve o PBS como: "Uma filosofia de design onde os participantes do protocolo podem usar serviços de terceiros durante suas funções de consenso." Até este ponto, os mineradores tinham controle total: eles decidiam a ordem das transações, faziam o hash e depois adicionavam o bloco. Mas o MEV GETH mudou as coisas. Ele introduziu atores externos, chamados de buscadores, que pagavam pelo direito de ter seu pacote de transações incluído no bloco dos mineradores.

Com o MEV GETH, os mineradores tinham um novo ponto final. Eles poderiam receber pacotes de transações otimizados para MEV dos buscadores. Cada pacote também conteria uma transação que fornecia aos mineradores uma taxa, incentivando-os a selecionar esse pacote específico. Naturalmente, os mineradores escolhiam o pacote que oferecia a maior taxa. Quando os buscadores competem por oportunidades de MEV na mempool pública, seus lances naturalmente aumentam devido a essa competição. Essa competição garante que os mineradores recebam a maior parte dos benefícios do MEV.

Vamos analisar isso com um exemplo: Imagine que Alice é uma pesquisadora e identifica uma oportunidade de arbitragem entre duas exchanges descentralizadas. Ela poderia lucrar 0.07 ETH comprando o Token X na UniSwap e imediatamente vendendo-o na SushiSwap por um preço mais alto. Então, ela cria um pacote de transações otimizado para a oportunidade MEV de 0.07 ETH e está disposta a pagar a um minerador 0.05 ETH para priorizar suas transações no próximo bloco. Bob, outro pesquisador, identifica a mesma oportunidade. Ele constrói um pacote semelhante, mas oferece um pagamento de 0.06 ETH aos mineradores pelo mesmo privilégio. Alice e Bob enviam seus pacotes de transações otimizadas para MEV aos mineradores. Do outro lado, um minerador recebe esses pacotes e precisa decidir qual incluir no próximo bloco. Naturalmente, o minerador escolhe o pacote de Bob devido à taxa mais alta oferecida, garantindo que o minerador obtenha o benefício máximo. É uma situação vantajosa para todos.

O minerador captura a maior parte da oportunidade de MEV, recebendo 0,06 ETH da oportunidade de 0,07 ETH. Enquanto isso, o pesquisador garante um lucro líquido de 0,01 ETH, que de outra forma não teriam sido capazes de obter. A essência do mecanismo MEV GETH é essa licitação competitiva. Alice e Bob competem entre si, oferecendo incentivos ao minerador, garantindo assim que o minerador capture uma parte significativa dos benefícios de MEV.

No entanto, se eles simplesmente abrirem um endpoint para qualquer um enviar os pacotes de mineradores, agentes mal-intencionados podem explorar essa abertura para sobrecarregar seu sistema, potencialmente lançando um ataque DOS. Para resolver essa vulnerabilidade, os Flashbots introduziram o Flashbots Relay. Esse relé tem um papel crucial de filtragem: ele avalia os pacotes de transações recebidos com base em sua lucratividade potencial para os mineradores, a validade das transações e a taxa oferecida. Apenas os pacotes ideais são então encaminhados aos mineradores. Esse método introduz um nível de centralização, pois o processo depende do Flashbots Relay para filtrar tráfego indesejável ou potencialmente prejudicial. Curiosamente, já existia um nível de PBS entre o operador do pool de mineração e seus trabalhadores. Normalmente, o operador construiu o corpo do bloco, incluindo os pacotes enviados dos relés, fez o hash do cabeçalho do bloco uma vez e o despachou para os trabalhadores para continuar o hashing e encontrar o nonce dourado.

Visão geral do MEV GETH: A jornada da pesquisa para a inclusão do pacote de transações no bloco do minerador

Parte Dois: O Cenário Atual

Quando o Ethereum fez a transição do Proof of Work (PoW) para o Proof of Stake (PoS), o cenário de validação de transações e proposta de blocos mudou significativamente. Enquanto o PoW dependia de mineradores e poder computacional (taxa de hash) para validar e adicionar novos blocos à blockchain, o PoS transferiu essa responsabilidade para validadores que apostariam seu ETH para se tornarem proponentes de bloco.

MEV GETH estava sendo usado por quase todos os grupos de mineração, mas com a transição do Ethereum para PoS, o sistema exigia modificações. PoS foi projetado para acomodar validadores individuais operando em dispositivos de baixo recurso como um Raspberry Pi. PoS foi projetado com o objetivo de garantir uma paisagem equilibrada: quer você seja um validador individual ou faça parte de um pool de validação substancial, não haveria vantagem inerente no processo de validação para nenhum participante. Antes da transição para PoS, alguns grupos de mineração dominavam a taxa de hash. Isso permitia uma relação de confiança entre esses grupos e o Flashbots Relay. Quaisquer ações desonestas, como um grupo de mineração roubando MEV de um pesquisador, poderiam comprometer essa relação. Digamos que um minerador recebesse um pacote com um ataque de sanduíche de um pesquisador. Se o minerador adicionalmente sanduichasse o pesquisador com suas próprias transações, isso traria ganhos a curto prazo, mas romperia os laços com o Flashbots, custando-lhes ganhos futuros de MEV porque perderiam o acesso ao Flashbots Relay.

Apresentando MEV Boost

Os validadores individuais, ao contrário dos grandes pools de mineração, podem não ter motivações de longo prazo para manter a confiança. Em certos cenários, eles podem achar mais lucrativo explorar o MEV de um construtor e posteriormente desaparecer da rede. Essa ação resultaria em serem totalmente penalizados, perdendo todos os 32 ETH, mas em alguns casos, o lucro potencial ao roubar o MEV pode superar essa perda. Isso de fato ocorreu em abril, quando um validador inescrupuloso desviou $20M de um bot de sanduíche antes de desligar seu validador.Leitura adicional sobre este incidente.

Em resposta a este novo vetor de ataque, a Flashbots lançou o MEV Boost, um sistema projetado para um ambiente com validadores individuais.

A Mecânica do Impulso de MEV:

• Relés: Ao contrário do sistema anterior, onde apenas os Flashbots atuavam como relé, o MEV Boost democratiza isso. Agora, qualquer um pode servir de revezamento, ampliando a participação e a segurança. O Flashbots também abriu seu código de relayer.
• Construtores: Um novo papel emerge - o Construtor. Essas entidades coletam pacotes de transações de buscadores e os combinam em blocos completos.
• Sistema de Leilão: Os construtores fazem lances para incluir seu bloco completo e os submetem aos retransmissores. Os retransmissores realizam uma etapa crucial de verificação para garantir a validade do bloco.
• Interação do Validador: Os relays encaminham a oferta mais alta, juntamente com o cabeçalho do bloco respectivo, que recebem dos construtores concorrentes para o validador que está com a vez de propor um bloco para a rede Ethereum.
• Compromisso de Bloqueio: O validador designado assina o cabeçalho do bloco, que é um compromisso. Uma vez assinado, eles estão vinculados a esse bloco. Se tentarem assinar outro bloco, isso seria visto como um ato malicioso e eles seriam punidos com perda de fundos.
• Proposta Final: Com um compromisso estabelecido, o relé envia os detalhes completos do bloco para o validador, e formalmente propõe à rede.

O processo de impulso do MEV

Esta configuração introduz problemas de confiança:

• Construtor-Relay Trust: Os construtores precisam confiar que os relays não irão roubar seu MEV. Considere um cenário em que um relay, após receber um bloco de um construtor, troca o endereço do construtor em uma transação de sandwich pelo seu próprio. Em seguida, eles passam o cabeçalho manipulado para o proponente.
• Confiança no Proposer-Relay: Por outro lado, os proponentes devem confiar que os cabeçalhos de bloco que assinam são válidos. Propor um bloco inválido resultaria na perda das recompensas do bloco, já que a rede rejeitaria tal bloco.

Projetos de design da PBS enfrentam um desafio recorrente: enquanto as interações entre o proponente e os atores de ordenação de transações são dadas, há uma clara necessidade de um mecanismo onde:

• Os proponentes podem se comprometer com um bloco do construtor sem saber o seu conteúdo, mas permanecem seguros quanto à validade do bloco.
• Os construtores podem enviar com segurança seu bloco ao proponente, confiantes de que seu MEV não será roubado.

MEV Aumenta suposições de confiança

Antes de mergulhar mais fundo no MEV Boost, é essencial entender a maneira padrão como o Ethereum cria blocos sem o uso do MEV Boost. Esta configuração depende da colaboração entre um Cliente de Execução de validadores e um Cliente de Consenso. Quando uma transação é recebida pelo Cliente de Execução, ele verifica o formato, a adiciona à sua mempool, mas não a processa. Simultaneamente, o Cliente de Consenso lida com o consenso de PoS, escolhendo um validador para criar o próximo bloco. O Cliente de Execução do validador selecionado então organiza as transações por preço de gás em um novo bloco, que é então encaminhado para o Cliente de Consenso e apresentado à rede. Outros validadores atestam a precisão do bloco e, uma vez verificado, ele se torna o elo mais recente da cadeia.

Esse processo muda se o validador optar por usar o MEV Boost. Validadores que integram o MEV Boost o fazem com seu cliente de consenso. Quando estão prontos para propor um bloco, eles não mais dependem de seu Cliente de Execução e, em vez disso, se conectam a uma rede de relays. Os validadores podem escolher a quais relays se conectar.

MEV Boost é opcional, mas 95% dos validadores estão utilizando. Essencialmente, quase todos os validadores, exceto aqueles administrados por Vitalik, estão delegando a construção de blocos para um terceiro. Essa delegação indica que uma função central do protocolo Ethereum, a construção de blocos, agora é realizada principalmente fora do próprio sistema Ethereum. Um jogador chave nessa configuração é o relé e seu papel contrasta um pouco com os princípios fundamentais do Ethereum. Atualmente, existem cerca de 9 relés ativos, mas apenas 6 deles têm mais de 9% de participação nos blocos transmitidos.

Desagregação dos principais relés e construtores por participação de mercado nos últimos 7 dias. Fonte: https://www.relayscan.io/

A confiança se torna um problema, uma vez que a relação entre os relays e o construtor e o relay e o validador não é sem confiança. Também há uma preocupação sobre resistência à censura. Os relays, durante seus leilões, têm a discricionariedade de determinar a validade dos blocos. Essa discricionariedade permite que eles excluam blocos com transações vinculadas a endereços sancionados. Um exemplo disso é quando as sanções do Tornado Cash da OFAC aconteceram, alguns relays exerceram esse poder. Dados recentes mostram que 38% dos blocos na semana passada seguiram as diretrizes da OFAC devido à censura imposta por tais relays.

Parte Três: Olhando para o Futuro

O Ethereum está elaborando uma estratégia para reincorporar os processos que atualmente operam fora de seu protocolo central. O objetivo é exigir que os proponentes obtenham blocos dos construtores, permitindo essencialmente que o protocolo lide com as funções atuais do relé. O sistema de relé, conforme está, tem suas vulnerabilidades. Por exemplo, um relé pode não validar corretamente um bloco, verificar erroneamente a oferta do construtor em relação ao pagamento destinado ao proponente, ou até mesmo atrasar ou falhar na entrega do bloco. Além disso, manter um relé não é barato. Atualmente, falta um modelo de financiamento sustentável para eles. O Ultrasound Relay, o relé mais utilizado, afirma que seus custos operacionais são estimados entre 70k-80k euros anualmente, e isso exclui outras despesas como manutenção de software. Os relés atualmente operam como serviços públicos.

Vale ressaltar que, como o MEV Boost é um software externo desenvolvido por uma empresa (Flashbots), ele não é tão rigorosamente testado quanto o software dentro do protocolo. Isso ficou evidente com o cliente Prism após a atualização Shapella: um bug de integração com o MEV Boost causou problemas com a assinatura do proponente, levando a slots perdidos e penalidades. O objetivo de integrar esse processo ao protocolo Ethereum é enfrentar esses desafios, garantindo que, mesmo se um acordo entre o proponente e o construtor se desfizer, o proponente permaneça reembolsado. Portanto, se um construtor fornecer um bloco defeituoso, o proponente ainda recebe o lance completo, deixando o construtor arcar com as consequências. Embora os detalhes dessa integração, referida como ePBS (separação de proponente-construtor consagrada), ainda estejam sendo pesquisados e possivelmente a alguns anos de realização, já existem muitas ideias diferentes de como ela poderia ser.

Como Separar o Proponente do Construtor

Para entender as implementações potenciais de ePBS, é essencial primeiro entender alguns componentes básicos do algoritmo PoS do Ethereum. No Ethereum, o tempo é segmentado em intervalos de 12 segundos chamados slots. 32 desses slots se juntam para formar uma época. Em cada slot, um validador é selecionado aleatoriamente para propor um bloco. Simultaneamente, um comitê é designado para atestar a validade do bloco que consideram conforme às regras de escolha de fork PoS do Ethereum, atestando idealmente o bloco mais recentemente proposto como a cabeça da blockchain. Se um bloco não for proposto no slot dado, então, 4 segundos depois, os validadores que atestam atestam o bloco anterior.

Agora, para os designs ePBS. O modelo mais favorecido abrange dois slots. Primeiro, há uma fase de licitação, onde os construtores enviam suas ofertas para os validadores. Então, o Slot 1 começa com o proponente escolhendo uma oferta e comprometendo-se com ela publicando um bloco que se compromete com a oferta do construtor. Um grupo de atestadores então emite seu voto a favor deste bloco, garantindo seu lugar na cadeia. No Slot 2, os construtores veem a oferta que foi comprometida no bloco comprometido do proponente e as atestações sobre ela. Reconhecendo o compromisso irreversível do proponente, o construtor cuja oferta foi selecionada lança seu bloco e tem a garantia de que seu MEV não pode ser roubado. Finalmente, os atestadores validam este novo bloco.

Projeto ePBS de “dois slots”

Um modelo recém-lançado é semelhante à abordagem de dois slots, mas introduz um comitê de pontualidade de carga útil. Primeiro, uma proposta do construtor é selecionada e comprometida pelo proponente, e então o comitê de validadores dá sua atestação. Posteriormente, o construtor revela a carga útil do bloco (suas transações), e o comitê de pontualidade de carga útil confirma que a carga útil foi fornecida a tempo e sua validade. As outras diferenças entre esses dois métodos residem nos detalhes das operações de Prova de Participação do Ethereum, mas isso está além do escopo deste post.

Design ePBS com um Comitê de Oportunidade de Carga Útil

Outro design gira em torno do conceito de um leilão de slot. Aqui, os construtores, durante sua oferta, comprometem-se com um slot na época sem especificar o bloco. Eles essencialmente se comprometem a criar um bloco durante seu slot alocado, oferecendo um certo preço para fazê-lo. Isso oferece adaptabilidade, especialmente para o MEV de domínio cruzado, que requer ação em tempo real.

Até agora, todos os designs de ePBS concedem ao construtor controle total sobre as transações do bloco. Uma solução alternativa potencial é o uso de uma lista de inclusão. Essa lista, enviada pelo proponente ao construtor, idealmente todas as transações atualmente na mempool ou não precisam estar, contém transações que devem fazer parte do bloco do construtor se houver espaço. Se o bloco do construtor estiver cheio, eles devem indicar isso, confirmando que reconheceram a lista. Tal método fortalece a resistência à censura da rede. Se um construtor deseja censurar uma transação, isso se tornará difícil e custoso ao longo do tempo. Devido ao EIP 1559, blocos consecutivamente preenchidos farão com que a taxa base aumente exponencialmente. Portanto, se um construtor censurar continuamente uma transação enchendo um bloco com transações fictícias, os custos crescentes tornam isso inviável com o tempo.

Pode haver casos em que o proponente deseja ter alguma influência na criação do bloco. Outra característica do ePBS pode envolver o proponente fazendo uma seção do bloco (seja o início ou o final) e delegando o restante a um construtor. Todos esses projetos e recursos não são mutuamente exclusivos, é mais sobre equilibrar seus benefícios e desvantagens.

A Abordagem de Revezamento Otimista

Outra abordagem sobre a ePBS aproveita nossos relés de confiança existentes. A ideia é reduzir incrementalmente as responsabilidades do relé até que ele sirva principalmente como otimizador, em vez de um componente crucial. Em sua primeira fase, eliminamos a responsabilidade do relé de verificar a validade do bloco. Isso reduz significativamente o custo de executar um relé, pois não há mais necessidade de simulação de bloco para garantir sua validade. Além disso, isso simplifica o papel do relé, reduzindo cerca de 100 a 200 milissegundos de latência em suas comunicações com os proponentes e construtores. Então, como garantimos que o proponente receba seu pagamento se um bloco se mostrar inválido? Os construtores seriam obrigados a postar garantia, igual ao lance deles, quando fizerem o lance. Se o bloco for inválido, a garantia cobre o pagamento que o proponente teria recebido. Esse conceito é chamado de Relé Otimista V1.

Reenvio Otimista V1

Levando a retransmissão otimista um passo adiante para V2, podemos eliminar a necessidade do relay de baixar o bloco, reduzindo mais 50 a 100 milissegundos de latência. As mesmas garantias se aplicam: se um bloco nunca é baixado, o colateral do construtor é pago.

Transmissão otimista V2

Por fim, o jogo final para a Revoada Otimista começa a se parecer muito com o modelo de comitê de pontualidade de carga que mencionei anteriormente. Eis a sequência: Os construtores enviam seus lances em uma camada peer to peer. O proponente aceita um lance e segue com um cabeçalho assinado. Em seguida, o construtor lança o bloco. Nesta fase, o trabalho exclusivo do relé é supervisionar o mempool da camada peer to peer, basicamente cronometrando quando diferentes atividades ocorrem. O papel do relé torna-se super leve, ele só precisa manter controle sobre o mempool. Isso faz com que o relé opere de maneira muito semelhante ao comitê de pontualidade de carga. Todos esses passos contribuem para um futuro em que o relé é substituído pelo comitê de pontualidade de carga, otimizando todo o protocolo.

Aproveitando os Construtores para Melhorias Adicionais no Protocolo

A PBS surgiu como resposta da Flashbots aos efeitos centralizadores do MEV, com o objetivo de tentar aproveitar o MEV para resultados positivos. Dado o novo papel no Ethereum especializado na construção de blocos, há uma oportunidade para essas entidades agirem como supercomputadores, contrastando com os validadores leves. Os projetos de protocolo estão surgindo para capitalizar esses construtores poderosos. A ideia é manter os validadores simples e diretos (alguns até podem dizer cucks) , enquanto os construtores, sem tais restrições, podem funcionar em um nível computacional muito mais alto. Uma aplicação primária para esses construtores aprimorados é a escalabilidade.

O designer Danksharding do pesquisador da Ethereum Dankrad Feist sugere que esses construtores altamente intensivos em recursos podem construir um único grande bloco que contém todos os dados. Esses dados são então segmentados e confirmados por múltiplos compromissos KZG. A construção deste bloco requer recursos consideráveis, mas validá-los é relativamente barato. Validadores leves podem então aplicar Amostragem de Disponibilidade de Dados para inspecionar uma pequena seção do bloco e estar quase certos da acessibilidade de todo o conjunto de dados, proporcionando um aumento adicional de cerca de 16 vezes na taxa de transferência de dados do Proto-Danksharding. As complexidades do Danksharding são complicadas e não são abordadas aqui, mas o ponto-chave é que esses construtores avançados podem ser designados para desempenhar papéis adicionais para aprimorar ainda mais a rede.

Outra ideia para aproveitar os construtores é a realização potencial de rollups baseados. Há alguns anos, Vitalik discutiu modelos de sequenciamento de rollup, cunhando o termo Total Anarchy para um deles, no qual qualquer pessoa pode publicar um bloco de rollup e a primeira sequência que atinge a cadeia é o bloco oficial. Esta abordagem teve muitas desvantagens, como spam onchain e ambiguidade sobre a sequência vencedora. No entanto, o artigo recente de Justin Drake sobre rollups baseadosdestacou uma estratégia mais eficiente aproveitando os construtores. Neste modelo, o construtor na camada um funciona como o sequenciador rollup, selecionando a sequência ótima para incluir onchain. Isso garante que apenas as sequências ótimas sejam incorporadas.

Além dos rollups, a introdução de construtores poderosos pode estimular outras estruturas inovadoras, como clientes sem estado. Eles capacitam os nós a operar como de costume, mas sem o ônus de preservar estados desatualizados. Isso permite que os nós sejam mais leves e dependam da capacidade do construtor de gerar provas criptográficas específicas.

PEPC: Compromissos de Proponente Aplicados pelo Protocolo

Compromissos de proponentes aplicados por protocolo (PEPC, pronunciado pepsi) é um conceito introduzido pelo pesquisador da Fundação Ethereum, Barnabé Monnot, em outubro de 2022. Você pode aprofundar-se na postagem original de Barnabé.aqui. No seu âmago, a PEPC tem como objetivo conceder aos proponentes uma maior voz na construção de blocos, que eles perderam ao vender a tarefa inteira para construtores especializados. Na PEPC, os proponentes podem adicionar condições extras para que um bloco seja considerado válido, além dos requisitos usuais do Ethereum. Se um bloco não atender a nenhuma dessas condições extras, é considerado inválido, e os atestadores devem rejeitá-lo. Isso difere dos compromissos da EigenLayer, onde os validadores com compromissos extras ou perdem parte do ETH apostado por não cumprimento ou são recompensados por cumpri-los. No entanto, o bloco permanece válido independentemente desses compromissos.

Imagine que Alice é uma proponente na rede Ethereum. Com PEPC, Alice tem a flexibilidade de fazer um compromisso específico para o próximo bloco. Ela poderia se comprometer a que seu bloco contenha pelo menos três transações referentes a um contrato inteligente específico, e ela está disposta a alocar 70% do gás do bloco para essas transações. Ela comunica esse compromisso, e ele se torna parte das condições de validade de seu bloco. Agora, Bob, um construtor, vê o compromisso de Alice. Ele agrupa um conjunto de transações que atendem aos critérios de Alice e o envia para ela. Se o bloco de Alice, depois de construído, estiver alinhado com seu compromisso (ou seja, contém as transações especificadas que consomem o gás designado), então o bloco é considerado válido e pode ser adicionado à blockchain. Caso contrário, o bloco de Alice não será aceito, garantindo que ela cumpra seus compromissos declarados.

Uma diferença chave entre ePBS e PEPC reside na natureza dos compromissos. No ePBS, os proponentes e Construtores seguem um procedimento fixo e uniforme. É uma espécie de abordagem universal. Um proponente se compromete com um hash de bloco específico e o construtor então produz um payload correspondente. No entanto, o PEPC introduz variedade. Cada proponente pode definir condições únicas, oferecendo muito mais flexibilidade. É crucial notar que a existência do PEPC depende do ePBS, eles se complementam. Os detalhes exatos do funcionamento do PEPC ainda estão em discussão e pesquisa.

Conclusão

PBS não é uma implementação específica, é uma filosofia de design. Diz que existem incentivos para a divisão do trabalho e que os atores do protocolo delegarão algumas responsabilidades a entidades externas mais especializadas. O objetivo do protocolo é oferecer uma interface confiável, o mais trustless possível, para garantir que essa delegação seja suave, justa e inclusiva. Sem isso, alguns atores podem ter vantagem, levando aos problemas de centralização primeiro observados com MEV antes da era da PBS. No seu cerne, a PBS enfatiza a justiça e a descentralização. Embora os elementos exatos a serem integrados no protocolo sejam vistos em futuras atualizações do Ethereum, o objetivo geral do Ethereum permanece claro: computação estatal acessível, aberta e confiável, supervisionada por um grupo descentralizado de validadores leves.

Aviso Legal:

1. Este artigo é reproduzido de Espelho]. Todos os direitos autorais pertencem ao autor original [Chaskin 链上]. Se houver objeções a esta reprodução, entre em contato com a equipe Gate Learn e eles lidarão com isso prontamente.
2. Isenção 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 Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.