Ethereum Block Building: A economia oculta por trás de cada transação

Block Building é um aspecto crucial do ciclo de vida do Ethereum, consistindo em várias partes móveis. Ele determina quais transações são incluídas em um bloco e em que ordem, impactando diretamente a eficiência da rede, a descentralização e a justiça. Com o tempo, o processo de produção de blocos do Ethereum evoluiu, especialmente com o papel crescente do MEV e a mudança da seleção orientada por validadores para construtores especializados.

Esta postagem discutirá como a construção de blocos do Ethereum evoluiu junto com a introdução da separação do Proposer Builder e pesquisas futuras.

Introdução aos componentes de construção de blocos Ethereum

Slots e Épocas

O Ethereum organiza o tempo em unidades discretas:

• Slot: Um slot é um período de 12 segundos no qual um único bloco pode ser proposto. Se nenhum validador enviar um bloco dentro de um slot, ele será ignorado.
• Época: Uma época consiste em 32 intervalos, totalizando 6,4 minutos .

No final de cada época, as tarefas do validador são embaralhadas para garantir a descentralização e a segurança. O Ethereum atinge a finalidade econômica após 2 épocas (~12,8 min) , após as quais é quase impossível reverter os blocos.

Comitês

O Ethereum tem um grande número de Validadores na rede. No momento da escrita, há 1.051.349 validadores ativos, de acordo com beaconcha.in . Seria inviável se tantos validadores tivessem que verificar cada bloco a cada 12 segundos. Portanto, os validadores são divididos em comitês para validar transações de forma eficiente e atestar a validade do bloco.

Cada comitê:

• Consiste em um subconjunto de validadores atribuídos aleatoriamente no início de uma época usando RANDAO.
• Garante que nenhum validador tenha influência desproporcional.
• Participa da votação (atestação) dos blocos e confirmação de sua validade.

O tamanho de um comitê depende do número total de validadores ativos na rede, mas geralmente cada comitê tem pelo menos 128 validadores.

Em cada slot:

• Digamos que há N Comitês atribuídos por slot e digamos que há M Validadores em cada Comitê (onde M >128). Isso significa que há NxM atestados para cada slot. Como você pode entender, pode rapidamente se tornar opressor para a rede fofocar sobre tantos atestados.

• Os agregadores em cada Comitê são encarregados de agregar as atestações de seus respectivos Comitês. Isso significa que de um Comitê de M Validadores, há apenas 1 Aggregated Attestation final em vez de M .

• Então, em cada slot, há um final de N Atestações (1 para cada comitê daquele slot) sendo fofocadas para o tópico global. O Proponente do próximo slot pega essas N atestações.

  
  

Alguns pontos a ter em mente

• Durante uma época, cada validador ativo é membro de exatamente um comitê, então todos os comitês da época são separados.

• O protocolo ajusta o número total de comitês em cada época de acordo com o número de validadores ativos.

• O projeto atual é ter 64 comitês por vaga, ou seja, N=64

  
  

Proponente Lookahead

O embaralhamento da cadeia de beacons é projetado para fornecer um mínimo de 1 Epoch (32 slots) lookahead nas próximas atribuições do comitê do validador para atestar ditadas pelo embaralhamento e slot. Observe que esse lookahead não se aplica à proposição, que deve ser verificada durante a epoch em questão.

get_committee_assignment pode ser chamado no início de cada época para obter a atribuição para a próxima época ( current_epoch + 1 ). Isso também permite que os validadores calculem o id da sub-rede, ingressem no respectivo comitê e estejam preparados para suas tarefas.

Além disso, um Validador pode ser designado como Aggregator de um comitê específico. Se for o caso, ele deve assinar o tópico respectivo também.

Responsabilidades do proponente

Dentro de cada slot, um único validador do respectivo comitê é selecionado como proponente para criar e enviar um bloco.

O papel do proponente é crucial, pois ele:

• Construa um bloco incluindo transações e atestados pendentes.
• Assine e transmita o SignedBeaconBlock para a rede.
• Ganhe recompensas por propor blocos válidos com sucesso.

Breve introdução ao MEV

MEV é o lucro adicional extraído pelos validadores (antigos mineradores) ao reordenar, incluir ou censurar as transações dentro de um bloco.

Algumas estratégias comuns de MEV são:

• Front-running : Colocar uma negociação logo antes de uma transação lucrativa conhecida. Frontrunning também é considerado um MEV tóxico, pois surpreende o usuário com um efeito negativo.
• Back-running : Executar uma transação logo após um evento específico (por exemplo, bots de arbitragem).
• Ataques sanduíche : uma combinação de front-running e back-running, especialmente em negociações DeFi.

Quem extrai o MEV?

• Validadores (pré-PBS) : quando os validadores controlavam a produção de blocos, eles tinham total discrição sobre a ordem das transações e podiam extrair MEV diretamente.
• Pesquisadores : Atores independentes que escaneiam o mempool em busca de oportunidades MEV e enviam transações adequadamente.
• Construtores (pós-PBS) : após o PBS, os construtores de blocos assumem o papel de construir blocos otimizados para MEV, enquanto os validadores simplesmente selecionam blocos do maior lance.

Construção de blocos pré-PBS: MEV centrado no validador

Antes da transição do Ethereum para o PBS, o proponente (anteriormente mineradores em PoW) tinha controle total sobre a ordenação de transações . Isso criou um ecossistema onde o MEV era extraído diretamente por validadores ou terceirizado para pesquisadores especializados.

Como funcionava antes da PBS:

1. Pool de transações : as transações são transmitidas normalmente e entram no mempool.
2. Os validadores selecionavam manualmente as transações do mempool. Elas poderiam ser ordenadas por algo chamado priority_fee , que são as taxas que o usuário está disposto a pagar para ser incluído primeiro. Também poderia ser ordenado de forma que o Validador tenha mais receita (por meio de sandwich/frontrunning).
3. O Validador constrói o bloco com base nas transações que ele escolheu.
4. Propagação de bloco : O bloco assinado é transmitido para a rede.

Isto é um pouco vagamente abstraído para simplificar. Mas este era o fluxo geral. Isto pode ser denominado como Vanilla Block Building

Problemas com a construção de blocos pré-PBS

• Centralização de energia MEV : grandes validadores tinham uma vantagem econômica sobre os menores devido à sua capacidade de extrair MEV com mais eficiência.
• Maior risco de censura : os validadores poderiam optar por excluir transações que não estivessem alinhadas com seus incentivos financeiros.
• Congestionamento de rede e altas taxas de gás : as disputas por transações de MEV levaram à utilização ineficiente do espaço do bloco, aumentando os custos para usuários regulares.

Construção de blocos pós-PBS: Separação de proponentes e construtores

Para abordar os riscos de centralização e ineficiências da construção de blocos controlada pelo validador, a Separação Propositor-Construtor (PBS) foi introduzida. O PBS divide as responsabilidades da produção de blocos entre duas entidades separadas:

1. Construtores de blocos : entidades especializadas na construção de blocos otimizados, muitas vezes incorporando estratégias MEV.
2. Proponentes de Blocos (Validadores) : Os validadores não constroem mais blocos eles mesmos; eles simplesmente selecionam o bloco mais lucrativo oferecido pelos construtores.

Como funciona após o PBS:

1. Construtores constroem blocos : os construtores de blocos competem para construir o bloco mais lucrativo, considerando as oportunidades de extração de MEV.
2. Licitação para inclusão de blocos : os construtores fazem lances para propor seus blocos aos validadores, garantindo que eles recebam a opção mais lucrativa.
3. Os validadores selecionam o lance mais alto : em vez de selecionar transações individuais, os validadores simplesmente escolhem o bloco do construtor com o lance mais alto, maximizando suas recompensas.

Como funciona a construção de blocos Ethereum agora

1. O usuário envia a transação por meio de uma carteira conectada via JSON-RPC.
2. Esta transação é enviada para o mempool público. Todas as transações são despejadas aqui antes de serem coletadas e validadas. Recentemente, os Private Orderflows ganharam destaque com a maioria dos grandes players optando por isso, já que é uma solução alternativa para transmitir suas transações ao público usando canais autorizados/privados. Confira o painel no Dune para mais insights.

3. Searchers → que são entidades externas que escaneiam o mempool continuamente para encontrar oportunidades MEV ( mais sobre isso abaixo ). Eles buscam as respectivas transações e inserem as suas próprias se e quando necessário para obter lucro. Então, eles criam um pacote dessas transações, cuja ordem deve ser mantida para que o Searcher obtenha lucro. Pacotes são transações ordenadas que devem ser executadas atomicamente. Junto com esse pacote, eles podem adicionar uma transação no final do pacote que denota um "suborno" ao Builder. Esse pacote é enviado ao Builder por meio da chamada eth_sendBundle .

   Observação : os pesquisadores são entidades externas e influenciam a ordem das transações, mas não participam da validação de blocos ou de decisões de consenso.

   

   
   

4. Construtores → A próxima entidade é o Construtor, que realmente constrói o bloco. Eles tentam maximizar tanto a receita de taxas quanto a receita de MEV. Eles incluem as transações agrupadas enviadas pelos Pesquisadores (esperançosamente em ordem) e aceitam o pagamento (suborno) enviado pelos Pesquisadores. Os Construtores constroem cargas úteis de execução usando transações recebidas.

   Eles preenchem os blocos com:

   1. Pacotes enviados pelos Searchers.

   2. Transações de alta prioridade.

   3. Ordene transações gerais tendo em mente maximizar a receita.

      
      

   Eles também definem o campo feeRecipient para seu próprio endereço, significando que receberão tanto os subornos do Searcher quanto todas as taxas das transações em seu bloco enviado. Os Builders enviam uma transação no final de seu bloco que serve como um suborno para o proponente, semelhante ao que o Searcher fez para o Builder.

   
   

5. Relays → O mercado Builder é um mercado competitivo com vários builders querendo que suas cargas úteis sejam finalizadas para ganhar as taxas. No entanto, a maioria dos blocos é construída por alguns Block Builders bem conhecidos, nomeadamente BeaverBuild e Titan. Para simplificar este processo para o Proponente real, os Relays são entidades intermediárias que validam as cargas úteis enviadas pelos vários Builders e escolhem aquela com o lucro/lance máximo. A comunicação Relay-Proposer usa um truque bacana semelhante a um Commit and Reveal para garantir que o Proponente não engane todas as entidades até este ponto. Mais aqui .

Colocando tudo junto

Comunicação do Proponente do Revezamento

É inteiramente possível que, ao receber o payload do bloco, o proponente desembrulhe o bloco, insira suas transações e altere a ordenação conforme sua preferência, bem como defina o feeRecipient para seu próprio endereço. Isso significaria que cada entidade que trabalhou no processo de construção do bloco até agora (Searcher → Builder → Relay) será enganada ou fará "MEV stealing". Para evitar isso, o Relay envia apenas o Header do Block Payload selecionado. Isso acontece quando o proponente faz a chamada eth_getPaylaodHeader . O Relay agora envia um PayloadHeader que contém o hash do corpo, o lance e a assinatura do construtor.

O proponente tem 2 opções neste momento:

• Para selecionar o PayloadHeader (também chamado de Blinded Block ) fornecido pelo Relay. Se for o caso, o proponente deve assinar o cabeçalho com sua chave e enviá-lo de volta ao Relay e, consequentemente, solicitar o PayloadBody usando a chamada eth_returnSignedHeader . Agora, o Relay executa a chamada eth_sendPayload que retorna todo o ExecutionPayload ao proponente. O Proponente então simplesmente propõe esse bloco à rede Ethereum Validator ou, mais especificamente, ao comitê ao qual foi atribuído.

  
  

• O Proponente pode escolher não aceitar o PayloadHeader enviado pelo Relay, caso em que ele deve construir o bloco ele mesmo. Isso inclui encontrar oportunidades de MEV e ordenar transações adequadamente. Claro, neste caso, o Proponente consegue manter toda a receita das taxas + MEV. No entanto, isso não é tão simples quanto parece. Encontrar MEV e otimizar a receita é uma tarefa bastante pesada em computação e há a possibilidade de que o proponente não consiga construir o bloco a tempo (12 segundos), portanto, haverá um slot perdido. Neste cenário, o proponente pode ser cortado da rede.

Mas no Caso 1, e se o Proponente não enviar o bloco enviado pelo Relay?

Bem, o proponente é obrigado a assinar o PayloadHeader por esse exato motivo. Antes de enviar o Header, o Relay envia o PayloadBody para um Escrow para guarda. Uma vez que o Relay recebe o PayloadHeader assinado do proponente, ele verifica a assinatura e envia o PayloadBody armazenado no escrow para o Proposer. Agora, digamos que o proponente não inclua esse Block. Ele constrói seu próprio bloco, ignorando a ordenação feita até então. Nesse caso, a assinatura não corresponderá, pois os cabeçalhos foram alterados.

O Construtor agora pode transmitir esses Cabeçalhos Assinados conflitantes para a rede e o Proponente pode ser excluído da rede.

O que está impedindo os construtores de censurar transações?

Bem, nada. O motivo mais comum pelo qual os Builders podem censurar uma transação é porque ela interage com endereços OFAC . Para simplificar, OFAC aborda transações interativas que podem ter repercussões legais, o que obviamente ninguém gostaria de ter sobre suas cabeças.

De acordo com o Censorship.pics, os blocos criados pelos Builders incluem apenas 0-7% de transações sancionadas pelo OFAC.

Como resolvemos isso?

Uma das soluções mais conhecidas para censura de transações no momento em que este artigo foi escrito são Inclusion Lists .

Listas de inclusões são uma lista de transações (junto com algo chamado Resumo) que são publicadas pelo Proponente do Slot N junto com a proposta do Bloco do Slot N.

As Listas de Inclusão impõem que as transações na lista devem ser incluídas no Bloco N ou no Bloco N+1, caso contrário, o bloco N+1 será inválido. Elas são chamadas de Listas de Inclusão de Encaminhamento.

É claro que esse design de ILs não permitirá 100% de resistência à censura, mas há pesquisas ativas em andamento para reforçar essas propostas e muitas otimizações interessantes que podem ser aplicadas para melhorar a estrutura de incentivos.

FOCIL

As Listas de Inclusão Forçadas pela Fork Choice (FOCIL) são um novo design proposto em 2024 que desenvolve e aprimora as Listas de Inclusão para aumentar a neutralidade confiável.

O FOCIL permite que vários Validadores forneçam sugestões na Lista de Inclusão para um slot específico. Para ser mais preciso, 16 Validadores são escolhidos aleatoriamente em cada slot para formar um Comitê de Lista de Inclusão. Cada um desses membros forma seu próprio IL local e o espalha para a rede. O Proponente coleta e agrega listas de inclusão locais disponíveis em um IL final. Os designs de IL são leves, pois não há necessidade de reconstruir o bloco para incluir essas transações; elas podem ser simplesmente anexadas ao bloco. A condição para um Bloco satisfazer o requisito de validação de IL é " O bloco é válido se contiver todas as transações de todos os ILs até que o bloco esteja cheio".

Benefícios do PBS para gerenciamento de MEV

• Descentralização da Extração de MEV : Os construtores de blocos, em vez de alguns poucos validadores grandes, lidam com a extração de MEV, reduzindo os riscos de centralização do validador. No entanto, esta é uma faca de dois gumes, pois no processo de mitigação da centralização do Validador, introduzimos a Centralização do Construtor, onde apenas alguns Construtores estão construindo uma grande porcentagem de Blocos.
• Distribuição de receita mais justa : os validadores ainda lucram com o MEV sem se envolver diretamente na extração, tornando a produção de blocos mais justa.
• Utilização mais eficiente do espaço do bloco : a competição entre construtores leva a blocos otimizados com melhor eficiência de gás.

Desafios da PBS

• Risco de centralização entre construtores : embora os validadores sejam descentralizados, alguns construtores dominantes ainda podem centralizar a extração de MEV.
• Confiança em relés MEV off-chain : a PBS atualmente depende de relés MEV-Boost, que operam off-chain, apresentando potenciais riscos de segurança como um ponto de falha.

Referências:

Separação Propositor-Construtor do Ethereum: Promessas e Realidades

Estado da pesquisa: resistência à censura na PBS

Censura do Construtor: o núcleo podre do ethereum

Wiki do EPF - PBS

Notas sobre PBS

Lista de inclusão de encaminhamento

Quem ganha os leilões de construção de blocos Ethereum e por quê?

FOCIL

Agradecimentos