Parte 1: Como Chegamos Aqui

O Ethereum foi inicialmente projetado com a ideia de que uma única parte lidaria com todo o processo de criação de blocos. Isso envolvia a agregação de transações da mempool, a elaboração do cabeçalho do bloco e a descoberta do nonce dourado na prova de trabalho ou simplesmente a assinatura do 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, ordenavam-nas com base no preço do gás, que significa o trabalho computacional de cada transação, e mantinham-se dentro do limite de gás por bloco. No entanto, com o surgimento das finanças descentralizadas (DeFi), essa abordagem à construção de blocos sofreu mudanças significativas.

A Ameaça da Centralização do MEV

No DeFi, a sequência pela qual as transações são ordenadas pode fazer uma grande diferença. Digamos que haja uma transação à espera na mempool que pretende trocar 1 ETH por BITCOIN (estou a falar do HarryPotterObamaSonic10Inu, claro) na UniSwap. A quantidade de BITCOIN que receberia baseia-se na taxa 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, acabará por receber menos BITCOIN porque a taxa de ETH para BITCOIN mudou. Dada a importância da ordem das transações, e os mineiros controlam esta ordenação, isso levou ao surgimento do que chamamos de MEV, ou Valor Extraível Mínimo/Maximal do Miner. O MEV representa o lucro potencial que um mineiro pode obter ao escolher quais transações incluir, excluir ou reorganizar.

MEV pode parecer inofensivo no início. Caramba, pode 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 de bloco e taxas de transação, agora há MEV em disputa. Mas a realidade está longe de ser inofensiva. Se não for controlado, o 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 TAEG por causa disso. Tentador, certo? Você está tudo dentro! Então, você envia seus 32 ETH para o contrato de staking e inicia um nó validador. Mas espere um minuto... Você está vendo apenas 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 entra a atração centralizadora. Mesmo que você seja um quant, seu computador simples, talvez um raspberry pi, não chega aos pés dos supercomputadores deles 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 MEV. Avance rápido e você pode ver um punhado desses gigantes essencialmente administrando a rede, um resultado centralizado verdadeiramente inquietante. Se é para isso que as coisas estão indo, então os objetivos fundamentais do Ethereum falharam. Uma rede dominada por alguns poucos selecionados pode 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, foi um dos primeiros identificadores do problema de MEV. Em agosto de 2017, publicou um blog intitulado "O Custo da Descentralização em 0x e EtherDelta." Este blog foi inspirado pelas vulnerabilidades de front-running que identificou durante o ICO 0x.

A execução frontal envolve a identificação de uma transação no mempool que visa trocar o Token A pelo Token B. Um pioneiro inicia então programaticamente uma transação semelhante que oferece um preço de gás mais alto. Essa estratégia garante que a transação do front-runner seja processada antes da original. Depois que a transação inicial é processada, o líder 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 front-runner. Como resultado, enquanto o favorito ganha lucro, o indivíduo por trás da transação original recebe menos do Token B. Embora os ataques sanduíche sejam 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 Front-runners Lucram à Custa dos Outros

Durante o boom do ICO, Phil e uma equipa implementaram um bot que ganhava cerca de um milhão de dólares anualmente. Depois de partilharem a sua metodologia no post do blog que mencionei anteriormente, vários bots semelhantes surgiram, criando um cenário competitivo onde os bots superavam os preços do gás uns dos outros para alcançar prioridade de transação. Isso levou Phil a implementar nós globalmente, capturando dados transacionais em tempo real. Esta pesquisa culminou na sua famosa Papel "Flash Boys 2.0", que aprofundou os desafios do MEV causados pelas trocas descentralizadas.

Aqui está uma divertida história relacionada que Phil compartilhou quando era um convidado no Tábua de CortarQuando Hayden Adams, o fundador da UniSwap, partilhou o seu design para aquilo que é agora a mais popular bolsa descentralizada em ethresear.ch, Phil imediatamente enviou as suas preocupações tanto para o Vitalik como para o Hayden. Phil acreditava que o design da UniSwap iria causar uma quantidade significativa de MEV, tornando-se um alvo principal para exploração e colocando os utilizadores em risco de reordenação de transações e ataques de sandwich. Vitalik respondeu sugerindo que estes poderiam ser vistos apenas como um mecanismo de taxa adicional para utilizar a blockchain. Phil ficou tão irritado com esta resposta e pensou que entidades financeiras poderosas como o Goldman Sachs iriam entrar e roubar o almoço dos pequenos investidores tal como o sistema financeiro atual. No entanto, com o tempo, Phil acabou por adotar a perspetiva de Vitalik (louvado seja o senhor Vitalik).

Reconhecendo a importância e os desafios do espaço MEV, Phil co-fundou a Flashbots, uma empresa focada em pesquisa e soluções no arena MEV. A Flashbots percebeu que o MEV vai existir e a missão da Flashbots é garantir que a existência do MEV não leve a um sistema onde ser uma pessoa má ou criar externalidades negativas é melhor para você individualmente e é 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, a Flashbots pensou que poderia haver uma maneira de aproveitar a energia do MEV para os usuários e subsidiar as pessoas que seguram a rede e também subsidiar transações na rede para oferecer à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.

Explorando MEV: O Papel de Leilões e Separação de Propositor-Construtor

Flashbots reconheceu que o monopólio dos mineiros sobre a ordenação de transações era um recurso valioso. O primeiro passo para democratizar o MEV envolveu a criação de um sistema de leilão para os direitos de ordenação de transações. Isso levou à criação do MEV GETH, que introduziu 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 seus deveres de consenso.' Até este ponto, os mineiros tinham controle total: decidiam a ordem das transações, faziam o hashing e depois adicionavam o bloco. Mas o MEV GETH mudou as coisas. Introduziu atores externos, chamados de pesquisadores, que pagavam pelo direito de ter seu pacote de transações incluído no bloco dos mineiros.

Com o MEV GETH, os mineiros tiveram um novo endpoint. Eles poderiam receber pacotes de transações otimizados para MEV de buscadores. Cada pacote também conteria uma transação que proporcionaria aos mineradores uma taxa, incentivando-os a selecionar esse pacote específico. Naturalmente, os mineiros escolheram o pacote que oferece a taxa mais alta. Quando os pesquisadores competem por oportunidades de MEV no mempool público, suas ofertas naturalmente aumentam devido a essa concorrência. Esta competição garante que os mineiros recebam a maior parte dos benefícios do MEV.

Vamos analisar isto com um exemplo: Imagine que a Alice é uma pesquisadora e identifica uma oportunidade de arbitragem entre duas bolsas 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. Assim, ela cria um pacote de transações otimizado para a oportunidade de 0,07 ETH MEV e está disposta a pagar 0,05 ETH a um mineiro 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 mineiros pelo mesmo privilégio. Tanto a Alice quanto o Bob enviam seus pacotes de transações otimizadas para MEV aos mineiros. Do outro lado, um mineiro recebe esses pacotes e tem que decidir qual incluir no próximo bloco. Naturalmente, o mineiro escolhe o pacote de Bob devido à taxa mais alta oferecida, garantindo que o mineiro obtenha o benefício máximo. É uma situação ganha-ganha.

O minerador captura a maior parte da oportunidade 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 teria sido capaz de obter. A essência do mecanismo MEV GETH é esta 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 do MEV.

No entanto, se simplesmente abrissem um ponto final para que qualquer pessoa enviasse pacotes aos mineiros, atores maliciosos poderiam explorar essa abertura para sobrecarregar seu sistema, potencialmente lançando um ataque DOS. Para lidar com essa vulnerabilidade, a Flashbots introduziu o Flashbots Relay. Este relay desempenha um papel crucial de filtragem: avalia os pacotes de transações recebidos com base na sua rentabilidade potencial para os mineiros, na validade das transações e na taxa oferecida. Apenas os pacotes ótimos são então encaminhados para os mineiros. Este método realmente introduz um nível de centralização, pois o processo depende do Flashbots Relay para filtrar o tráfego indesejável ou potencialmente prejudicial. Curiosamente, já existia um nível de PBS entre o operador da piscina de mineração e seus trabalhadores. Tipicamente, o operador construía o corpo do bloco, incluindo os pacotes enviados dos relays, hashava o cabeçalho do bloco uma vez e enviava-o aos trabalhadores para continuar a fazer hash e encontrar o nonce dourado.

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

Parte Dois: O Panorama Atual

Quando o Ethereum fez a transição do Proof of Work (PoW) para o Proof of Stake (PoS), o panorama da 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 a ser utilizado por quase todas as pools de mineração, mas com a transição do Ethereum para PoS, o sistema necessitava de modificações. O PoS foi concebido para acomodar stakers individuais: validadores individuais a operar em dispositivos de baixos recursos, como um Raspberry Pi. O PoS foi concebido com o objetivo de garantir um panorama equilibrado: quer seja um staker individual ou faça parte de uma pool de staking substancial, não haveria vantagem inerente no processo de validação para qualquer participante. Antes da transição para PoS, algumas pools de mineração dominavam a taxa de hash. Isto permitia uma relação de confiança entre estas pools e o Flashbots Relay. Quaisquer ações desonestas, como uma pool de mineração a roubar MEV de um pesquisador, poderiam pôr em risco essa relação. Digamos que um mineiro recebeu um conjunto com um ataque de sandwich de um pesquisador. Se o mineiro sandwichar ainda mais o pesquisador com as suas próprias transações, isso traria ganhos a curto prazo, mas cortaria os laços com a Flashbots, custando-lhes ganhos futuros de MEV porque perderiam o acesso ao Flashbots Relay.

Apresentando o MEV Boost

Os validadores individuais, ao contrário das grandes pools de mineração, podem não ter motivações de longo prazo para manter a confiança. Em certos cenários, poderiam achar mais lucrativo explorar o MEV de um construtor e posteriormente desaparecer da rede. Esta ação resultaria na perda total deles, sendo penalizados, perdendo todos os 32 ETH, mas em alguns casos, o lucro potencial ao roubar o MEV pode superar essa perda. Isto de fato ocorreu em abril, quando um validador desonesto obteve $20M de um bot de sandwich antes de desligar seu validador.Leitura adicional sobre este incidente.

Em resposta a este novo vetor de ataque, a Flashbots implementou o MEV Boost, um sistema projetado para um ambiente com stakers individuais.

A Mecânica do Aumento de MEV:

• Relays: Ao contrário do sistema anterior, onde apenas os Flashbots atuavam como relay, o MEV Boost democratiza isso. Agora, qualquer pessoa pode servir como relay, ampliando a participação e a segurança. Os Flashbots também abriram o código de seu relayer.
• Construtores: Surge um novo papel - o Construtor. Essas entidades coletam pacotes de transações dos pesquisadores e os combinam em blocos completos.
• Sistema de Leilão: Os construtores fazem ofertas para incluir o bloco completo deles e submetê-los aos retransmissores. Os retransmissores realizam uma etapa crucial de verificação para garantir a validade do bloco.
• Interação do Validador: Os relés encaminham a oferta mais alta, juntamente com o cabeçalho do bloco respectivo, que recebem dos construtores concorrentes para o validador que tem de propor um bloco à rede Ethereum.
• Compromisso de Bloco: 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.
• Proposta Final: Com um compromisso estabelecido, o relé envia os detalhes completos do bloco para o validador, e é formalmente proposta para a rede.

O processo de impulso do MEV

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

• Confiança do Construtor-Relay: Os construtores precisam confiar que os relays não irão roubar o seu MEV. Considere um cenário onde um relay, depois de receber um bloco de um construtor, troca o endereço do construtor numa transação de sandwich pelo seu próprio. Em seguida, passam o cabeçalho manipulado para o proponente.
• Proposer-Relay Trust: 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, uma vez que a rede rejeitaria tal bloco.

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

• Os proponentes podem comprometer-se com um bloco do construtor sem conhecer o seu conteúdo, mas permanecem assegurados da validade do bloco.
• Os construtores podem enviar com segurança o seu bloco para o proponente, confiantes de que o seu MEV não será roubado.

MEV Aumentar pressupostos de confiança

Antes de mergulhar mais fundo no MEV Boost, é essencial entender a forma 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, adiciona-a à sua mempool, mas não a processa. Simultaneamente, o Cliente de Consenso lida com o consenso PoS, selecionando um validador para criar o próximo bloco. O Cliente de Execução do validador selecionado então organiza transações por preço de gás num novo bloco, que é então encaminhado para o Cliente de Consenso e lançado na rede. Outros validadores atestam a precisão do bloco e, uma vez verificado, torna-se o elo mais recente da cadeia.

Este processo muda se o validador optar por usar o MEV Boost. Os validadores que integram o MEV Boost fazem-no com o seu cliente de consenso. Quando estão prontos para propor um bloco, já não dependem do seu Cliente de Execução e, em vez disso, ligam-se a uma rede de relés. Os validadores podem escolher a que relés se conectar.

O MEV Boost é opcional, mas 95% dos validadores estão a utilizá-lo. Praticamente todos os validadores, exceto aqueles geridos por Vitalik, estão a delegar a construção de blocos a uma terceira parte. Esta delegação indica que uma função central do protocolo Ethereum, a construção de blocos, é agora principalmente conduzida fora do próprio sistema Ethereum. Um dos principais intervenientes neste cenário é o relay e o seu papel contrasta de certa forma com os princípios fundamentais do Ethereum. Atualmente, existem cerca de 9 relays ativos, mas apenas 6 deles têm uma quota de blocos retransmitidos superior a 9%.

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 torna-se uma questão, uma vez que a relação entre os relays e o construtor e o relay e o validador não é sem confiança. Há também uma preocupação com a resistência à censura. Os relays, durante os seus leilões, têm a discrição de determinar a validade dos blocos. Essa discrição permite-lhes excluir blocos com transações ligadas a endereços sancionados. Um caso em questão é quando as sanções da Tornado Cash da OFAC aconteceram, alguns relays exerceram esse poder. Dados recentes mostram que 38% dos blocos na semana passada aderiram às diretrizes da OFAC devido à censura imposta por esses relays.

Parte Três: Perspetivas Futuras

A Ethereum está a elaborar uma estratégia para reincorporar os processos que atualmente operam fora do seu protocolo central. O objetivo é obrigar os proponentes a obter blocos dos construtores, permitindo essencialmente que o protocolo lidere as funções atuais do relay. O sistema de relay, tal como está, tem as suas vulnerabilidades. Por exemplo, um relay pode não validar corretamente um bloco, verificar incorretamente a proposta 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 relay não é barato. Atualmente, falta um modelo de financiamento sustentável para eles. O Ultrasound Relay, o relay mais utilizado, afirma que os seus custos operacionais são estimados entre 70k-80k euros anualmente, e isso exclui outras despesas como a manutenção de software. Os relays operam atualmente como utilitários públicos.

Também vale a pena notar que, uma vez que o MEV Boost é um software externo desenvolvido por uma empresa (Flashbots), não é tão rigorosamente testado como o software dentro do protocolo. Isso foi 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 slashing. O objetivo de integrar esse processo no protocolo Ethereum é enfrentar esses desafios, garantindo que mesmo se um acordo entre o proponente e o construtor se desfizer, o proponente permanece reembolsado. Assim, se um construtor fornecer um bloco defeituoso, o proponente ainda recebe o lance total, deixando o construtor arcar com as consequências. Embora os detalhes dessa integração, referida como ePBS (separação proponente-construtor consagrada), ainda estejam sendo pesquisados e possivelmente a alguns anos da realização, já existem muitas ideias diferentes de como ela poderia ser.

Como consagrar a separação entre proponente e construtor

Para entender as possíveis implementações do ePBS, é essencial primeiro compreender alguns componentes básicos do algoritmo de PoS da Ethereum. Na 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 compatível com as regras de escolha de fork do PoS da Ethereum, idealmente atestando o bloco proposto mais recentemente como o cabeçalho do blockchain. Se um bloco não for proposto no slot dado, então, 4 segundos depois, os validadores atestam o bloco anterior.

Agora, para os projetos ePBS. O modelo mais favorecido abrange dois slots. Primeiro, há uma fase de licitação, onde os construtores enviam suas propostas para os validadores. Em seguida, 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 votou então a favor deste bloco, garantindo o seu lugar na cadeia. No Slot 2, os construtores veem a licitação que foi cometida no bloco comprometido do proponente e os atestados sobre ele. Reconhecendo o compromisso irreversível do proponente, o construtor cuja proposta foi selecionada libera seu bloco e tem a certeza de que seu MEV não pode ser roubado. Finalmente, os atestadores validam este novo bloco.

Design ePBS de “dois slots”

Um modelo recém-lançado é semelhante à abordagem de dois slots, mas introduz um comitê de pontualidade de carga. Primeiro, uma proposta de construção é selecionada e comprometida pelo proponente, e depois 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 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.

ePBS design com um Comité de Oportunidade de Carga

Outro design gira em torno do conceito de um leilão de slot. Aqui, os construtores, durante o seu lance, comprometem-se com um slot na época sem especificar o bloco. Essencialmente, comprometem-se a criar um bloco durante o seu slot alocado, oferecendo um certo preço para tal. 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. Esta 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, afirmando que reconheceram a lista. Tal método fortalece a resistência à censura da rede. Se um construtor quiser censurar uma transação, tornar-se-á cada vez mais difícil e dispendioso fazê-lo ao longo do tempo. Devido ao EIP 1559, blocos preenchidos consecutivamente farão com que a taxa base aumente exponencialmente. Portanto, se um construtor continuar a censurar uma transação preenchendo 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 funcionalidade do ePBS pode envolver o proponente a criar uma parte do bloco (seja o início ou o fim) e delegar o restante a um construtor. Todos esses designs e funcionalidades não são mutuamente exclusivos, é mais sobre equilibrar seus benefícios e desvantagens.

A abordagem de retransmissão otimista

Outra abordagem ao ePBS aproveita os nossos relés de confiança existentes. A ideia é reduzir incrementalmente as responsabilidades do relé até que sirva principalmente como um otimizador, em vez de um componente crucial. Na sua primeira fase, eliminamos a responsabilidade do relé de verificar a validade do bloco. Isto reduz significativamente o custo de operar um relé, uma vez que já não é necessário simular o bloco para garantir a sua validade. Além disso, simplifica o papel do relé, reduzindo cerca de 100 a 200 milissegundos de latência nas comunicações com os proponentes e construtores. Então, como garantimos que o proponente recebe o seu pagamento se um bloco se revelar inválido? Os construtores seriam obrigados a depositar uma garantia, igual à sua oferta, quando fizerem a oferta. Se o bloco for inválido, a garantia cobre o pagamento que o proponente teria recebido. Este conceito é denominado de Relaying Otimista V1.

Transmissão Otimista V1

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

Transmissão otimista V2

No final, o jogo final para a Reativação Otimista começa a parecer muito com o modelo de comitê de prontidão da carga que mencionei anteriormente. Aqui está a sequência: Os construtores submetem suas ofertas em uma camada de peer to peer. O proponente aceita uma oferta e segue com um cabeçalho assinado. Em seguida, o construtor implementa o bloco. Nesta fase, o único trabalho do relé é supervisionar o mempool da camada peer to peer, basicamente cronometrando quando diferentes atividades ocorrem. O papel do relé se torna muito leve, ele só precisa ficar de olho no mempool. Isso faz com que o relé opere muito como o comitê de prontidão da carga. Todos esses passos contribuem para um futuro em que o relé é substituído pelo comitê de prontidão da carga, simplificando todo o protocolo.

Aproveitando Construtores para Melhorias Adicionais no Protocolo

A PBS surgiu como uma resposta da Flashbots aos efeitos de centralização 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. Estão surgindo designs de protocolos que capitalizam esses construtores poderosos. A ideia é manter os validadores simples e diretos (alguém até poderia dizer cucks) enquanto os construtores, sem tais restrições, podem funcionar a um nível computacional muito mais elevado. Uma aplicação primária para esses construtores melhorados é a escalabilidade.

O design Danksharding do pesquisador da Ethereum Dankrad Feist sugere que esses construtores altamente intensivos em recursos podem construir um grande bloco que contém todos os dados. Esses dados são então segmentados e comprometidos por múltiplos compromissos KZG. A construção deste bloco requer recursos consideráveis, mas validá-los é relativamente barato. Os validadores leves podem então aplicar a Amostragem de Disponibilidade de Dados para inspecionar uma pequena seção do bloco e ter quase certeza da acessibilidade de todo o conjunto de dados, proporcionando um aumento adicional de ~16x 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 delegados a funções 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 para um deles Total Anarchy, 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 de rollup, escolhendo a sequência ótima para incluir onchain. Isso garante que apenas as sequências ótimas sejam incorporadas.

Para além dos rollups, a introdução de construtores poderosos pode impulsionar outras estruturas inovadoras, como clientes sem estado. Permitem que os nós operem como de costume, mas sem o fardo 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 Implementados por Protocolo

Compromissos de proponente aplicados pelo protocolo (PEPC, pronunciado pepsi) é um conceito introduzido pelo pesquisador da Ethereum Foundation, Barnabé Monnot, em outubro de 2022. Você pode aprofundar-se na postagem original de Barnabéaqui. No seu cerne, o PEPC visa conceder aos proponentes um maior poder na construção de blocos, que perderam ao vender toda a tarefa a construtores especializados. No PEPC, os proponentes podem adicionar condições extras para que um bloco seja considerado válido, além dos requisitos habituais do Ethereum. Se um bloco não cumprir nenhuma destas condições extras, é considerado inválido, e os atestadores devem rejeitá-lo. Isto é diferente dos compromissos da EigenLayer, onde os validadores com compromissos extras ou perdem algum ETH apostado por não cumprimento, ou são recompensados por cumpri-los. No entanto, o bloco permanece válido independentemente destes compromissos.

Imagine que Alice é uma proponente na rede Ethereum. Com o PEPC, Alice tem a flexibilidade de fazer um compromisso específico para o próximo bloco. Ela poderia comprometer-se a que o seu bloco contenha pelo menos três transações relativas a um contrato inteligente específico e está disposta a alocar 70% do gás do bloco para estas. Ela comunica este compromisso, e ele torna-se parte das condições de validade do seu bloco. Agora, Bob, um Construtor, vê o compromisso de Alice. Ele junta um conjunto de transações que correspondem aos critérios de Alice e envia-o para ela. Se o bloco de Alice, depois de ser construído, estiver alinhado com o 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. Se não, o bloco de Alice não será aceite, garantindo que ela cumpra os seus compromissos declarados.

Uma diferença fundamental 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 única para todos. Um proponente compromete-se com um hash de bloco específico, e o construtor produz então 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, complementam-se mutuamente. 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 confiável 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 observados pela primeira vez com o MEV antes da era do PBS. Em seu cerne, o 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 é reimpresso de Espelho]. Todos os direitos autorais pertencem ao autor original [Chaskin 链上]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles lidarão 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 do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.