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: 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. Slot: Uma época consiste em 32 intervalos, totalizando . Época: 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 , após as quais é quase impossível reverter os blocos. 2 épocas (~12,8 min) Comitês tem um grande número de Validadores na rede. No momento da escrita, há 1.051.349 validadores ativos, de acordo com . Seria inviável se tantos validadores tivessem que verificar cada bloco a cada 12 segundos. Portanto, os validadores são divididos em para validar transações de forma eficiente e atestar a validade do bloco. O Ethereum beaconcha.in comitês 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á Comitês atribuídos por slot e digamos que há Validadores em cada Comitê (onde >128). Isso significa que há atestados para cada slot. Como você pode entender, pode rapidamente se tornar opressor para a rede fofocar sobre tantos atestados. N M M NxM 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 Validadores, há apenas 1 final em vez de . M Aggregated Attestation M Então, em cada slot, há um final de Atestações (1 para cada comitê daquele slot) sendo fofocadas para o tópico global. O Proponente do próximo slot pega essas atestações. N N 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 comitês por vaga, ou seja, 64 N=64 Proponente Lookahead O embaralhamento da cadeia de beacons é projetado para fornecer um mínimo de lookahead nas próximas atribuições do comitê do validador para atestar ditadas pelo embaralhamento e slot. que esse lookahead não se aplica à proposição, que deve ser verificada durante a epoch em questão. 1 Epoch (32 slots) Observe pode ser chamado no início de cada época para obter a atribuição para a próxima época ( ). Isso também permite que os validadores calculem o id da sub-rede, ingressem no respectivo comitê e estejam preparados para suas tarefas. get_committee_assignment current_epoch + 1 Além disso, um Validador pode ser designado como de um comitê específico. Se for o caso, ele deve assinar o tópico respectivo também. Aggregator Responsabilidades do proponente Dentro de cada slot, um é selecionado como para criar e enviar um bloco. único validador do respectivo comitê proponente O papel do proponente é crucial, pois ele: Construa um bloco incluindo transações e atestados pendentes. Assine e transmita o para a rede. SignedBeaconBlock 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: : 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. Front-running : Executar uma transação logo após um evento específico (por exemplo, bots de arbitragem). Back-running : uma combinação de front-running e back-running, especialmente em negociações DeFi. Ataques sanduíche Quem extrai o MEV? : 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. Validadores (pré-PBS) : Atores independentes que escaneiam o mempool em busca de oportunidades MEV e enviam transações adequadamente. Pesquisadores : 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. Construtores (pós-PBS) 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 . Isso criou um ecossistema onde o MEV era extraído diretamente por validadores ou terceirizado para pesquisadores especializados. controle total sobre a ordenação de transações Como funcionava antes da PBS: : as transações são transmitidas normalmente e entram no mempool. Pool de transações Os validadores selecionavam manualmente as transações do mempool. Elas poderiam ser ordenadas por algo chamado , 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). priority_fee O Validador constrói o bloco com base nas transações que ele escolheu. : O bloco assinado é transmitido para a rede. Propagação de bloco 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 : grandes validadores tinham uma vantagem econômica sobre os menores devido à sua capacidade de extrair MEV com mais eficiência. Centralização de energia MEV : os validadores poderiam optar por excluir transações que não estivessem alinhadas com seus incentivos financeiros. Maior risco de censura : as disputas por transações de MEV levaram à utilização ineficiente do espaço do bloco, aumentando os custos para usuários regulares. Congestionamento de rede e altas taxas de gás 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, foi introduzida. O PBS divide as responsabilidades da produção de blocos entre duas entidades separadas: a Separação Propositor-Construtor (PBS) : entidades especializadas na construção de blocos otimizados, muitas vezes incorporando estratégias MEV. Construtores de blocos : Os validadores não constroem mais blocos eles mesmos; eles simplesmente selecionam o bloco mais lucrativo oferecido pelos construtores. Proponentes de Blocos (Validadores) Como funciona após o PBS: : os construtores de blocos competem para construir o bloco mais lucrativo, considerando as oportunidades de extração de MEV. Construtores constroem blocos : os construtores fazem lances para propor seus blocos aos validadores, garantindo que eles recebam a opção mais lucrativa. Licitação para inclusão de blocos : em vez de selecionar transações individuais, os validadores simplesmente escolhem o bloco do construtor com o lance mais alto, maximizando suas recompensas. Os validadores selecionam o lance mais alto Como funciona a construção de blocos Ethereum agora O usuário envia a transação por meio de uma carteira conectada via JSON-RPC. Esta transação é enviada para o mempool público. Todas as transações são despejadas aqui antes de serem coletadas e validadas. Recentemente, 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 para mais insights. os Private Orderflows Dune → que são entidades externas que escaneiam o mempool continuamente para encontrar oportunidades MEV ( ). 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 . Searchers mais sobre isso abaixo eth_sendBundle : 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. Observação → 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. Construtores Eles preenchem os blocos com: Pacotes enviados pelos Searchers. Transações de alta prioridade. Ordene transações gerais tendo em mente maximizar a receita. Eles também definem o campo 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. feeRecipient : os construtores são entidades externas e não interagem diretamente com o blockchain. Observação → 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 e 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 . Relays BeaverBuild Titan. 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 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 . O Relay agora envia um que contém o hash do corpo, o lance e a assinatura do construtor. feeRecipient eth_getPaylaodHeader PayloadHeader O proponente tem 2 opções neste momento: Para selecionar o (também chamado de ) 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 usando a chamada . Agora, o Relay executa a chamada que retorna todo o ao proponente. O Proponente então simplesmente propõe esse bloco à rede Ethereum Validator ou, mais especificamente, ao comitê ao qual foi atribuído. PayloadHeader Blinded Block PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload O Proponente pode escolher não aceitar o 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. PayloadHeader Mas no Caso 1, e se o Proponente não enviar o bloco enviado pelo Relay? Bem, o proponente é obrigado a assinar o por esse exato motivo. Antes de enviar o Header, o Relay envia o para um para guarda. Uma vez que o Relay recebe o assinado do proponente, ele verifica a assinatura e envia o 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. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Observação é uma infração punível com corte assinar dois cabeçalhos diferentes para o mesmo slot de proposta. 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 os blocos criados pelos Builders incluem apenas 0-7% de transações sancionadas pelo OFAC. o Censorship.pics, 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 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. Listas de inclusões 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. : Há também uma noção para que faz IL para o atual Bloco N em si. Mas esse design tinha falhas econômicas que levaram às Nota Listas de Inclusão Spot Listas de Inclusão Forward. É 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 são um novo design proposto em 2024 que desenvolve e aprimora as Listas de Inclusão para aumentar a neutralidade confiável. As Listas de Inclusão Forçadas pela Fork Choice (FOCIL) 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". : Os membros do comitê IL não podem garantir nenhuma forma de ordenação de transação, pois as transações IL podem ser incluídas em qualquer ordem. Eles apenas garantem a inclusão da transação. Nota Benefícios do PBS para gerenciamento 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. Descentralização da Extração de MEV : os validadores ainda lucram com o MEV sem se envolver diretamente na extração, tornando a produção de blocos mais justa. Distribuição de receita mais justa : a competição entre construtores leva a blocos otimizados com melhor eficiência de gás. Utilização mais eficiente do espaço do bloco Desafios da PBS : embora os validadores sejam descentralizados, alguns construtores dominantes ainda podem centralizar a extração de MEV. Risco de centralização entre construtores : a PBS atualmente depende de relés MEV-Boost, que operam off-chain, apresentando potenciais riscos de segurança como um ponto de falha. Confiança em relés MEV off-chain 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 Obrigado a , e pela revisão e sugestões. @mteam @Gajpower @unnawut
