Ethereum explora FOCIL e FairFIL para aprimorar os mecanismos de anti-censura

No mundo da blockchain, frequentemente ouvimos uma palavra: "censura resistente".

Muitas pessoas, ao ouvir pela primeira vez, podem achar que soa como um slogan politizado, até mesmo com certa conotação anarquista, mas para uma rede de liquidação aberta a usuários globais como a Ethereum, a resistência à censura não é primeiro uma posição política, mas sim uma capacidade técnica muito específica.

Imagine que você iniciou uma transação na sua carteira imToken.

Assinatura correta, saldo da conta suficiente e taxas de gas também não são baixas, mas a transação ainda não foi incluída em um bloco, e o estado na carteira permanece como "Pendente", enquanto outras transações com taxas semelhantes ou até mais baixas continuam sendo incluídas na cadeia.

A questão então se torna: quem tem o direito de decidir se uma transação pode ou não entrar em um bloco? Após tudo, se a Ethereum ainda depender de alguns participantes centralizados para decidir quais transações podem ser incluídas na cadeia, então não há diferença essencial entre ela e o sistema financeiro tradicional.

Portanto, nos últimos anos, a Ethereum tem explorado uma série de mecanismos anti-censura, como FOCIL e FairFIL, tentando responder a uma questão que parece simples, mas é na verdade muito crítica: como garantir que qualquer transação que cumpra as regras do protocolo tenha uma oportunidade justa de entrar em um bloco?

Para entender por que a Ethereum precisa desses mecanismos, primeiro é preciso compreender o que acontece com uma transação após ser enviada da carteira.

Quando o usuário assina e envia uma transação na carteira, essa transação geralmente entra primeiro no pool público de transações da Ethereum, conhecido como mempool, que funciona mais como uma área de espera contendo muitas transações aguardando para serem incluídas em blocos.

Mas entrar na fila de espera não significa que a transação já foi registrada na blockchain; ainda é necessário que alguém selecione as transações, determine sua ordem, agrupe-as em um bloco completo e envie para a rede confirmar.

A questão surge justamente nessa etapa.

Após a atualização da Ethereum para o mecanismo PoS (Proof of Stake), para evitar que grandes pools de staking explorem o MEV (Maximal Extractable Value) e criem monopólios econômicos, a Ethereum introduziu o sistema PBS (Proposer-Builder Separation, Separação entre Propositores e Construtores), no qual o processo de processamento de cada transação da Ethereum é dividido entre dois papéis:

• Builder: responsável por coletar transações, organizar a ordem das transações, identificar oportunidades de arbitragem e liquidação, e construir um bloco com o maior lucro possível;
• Proposer: responsável por selecionar um dos blocos candidatos enviados pelo Builder e submetê-lo à rede;

Este arranjo tem benefícios práticos.

É bem sabido que, nos últimos anos, as estratégias de MEV tornaram-se cada vez mais complexas, e exigir que cada validador comum realize independentemente a ordenação de transações e a otimização de blocos certamente daria vantagem aos grandes nós com mais capital, dados e capacidade técnica.

Portanto, delegue o trabalho complexo de construção de blocos a Builders profissionais; nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nós, nous A tradução fornecida está incorreta e contém repetições absurdas. Aqui está a versão correta: Portanto, delegue o trabalho complexo de construção de blocos a builders profissionais; mesmo nodos de validação comuns, sem capacidade avançada de arbitragem, podem participar da proposta de blocos e receber recompensas correspondentes, reduzindo o impacto do MEV na descentralização do staking.

Mas ele também acidentalmente trouxe outro efeito colateral: a concentração excessiva do direito de construção de blocos. Por exemplo, atualmente mais de 90% dos blocos da Ethereum em toda a rede são produzidos apenas por alguns poucos builders profissionais, e como esses builders geralmente possuem antecedentes empresariais claros, são facilmente sujeitos a pressões externas relacionadas à conformidade legal de países ou regiões específicas (por exemplo, listas de sanções OFAC), o que na prática já constitui um risco de centralização.

Por essa razão, assim que esses principais Builders selecionarem filtrar certas transações de contratos sensíveis (como o Tornado Cash) ou endereços específicos, essas transações ficarão presas em longos períodos sem serem incluídas em blocos, correndo o risco de serem "baniu implicitamente".

Em resumo, para usuários comuns, a Ethereum é uma rede aberta onde qualquer um pode se conectar, transferir fundos e chamar contratos inteligentes; no entanto, do ponto de vista do funcionamento do protocolo, enviar uma transação é apenas o primeiro passo — sua efetivação depende de ser selecionada, ordenada e incluída em um bloco por um construtor de blocos.

Portanto, a discussão sobre a "censura resistente" da Ethereum não é apenas um conceito amplo relacionado à política, regulamentação ou sanções; é primeiro um problema técnico muito específico:

When a transaction meets the protocol rules, can the network guarantee it an opportunity to be included in a block within a reasonable time?

Na verdade, até aqui, a questão já está clara: o Builder pode aumentar a eficiência da construção de blocos, mas se o poder de inclusão de transações permanecer a longo prazo nas mãos de poucos Builders, a Ethereum correrá o risco de formar novamente um novo monopólio centralizado.

For this purpose, Ethereum researchers proposed Inclusion Lists, commonly known as "inclusion lists."

O nome soa um pouco abstrato, mas sua lógica central não é complicada — o Builder ainda é responsável por criar os blocos, mas não pode decidir sozinho quais transações são incluídas ou excluídas; os nós de validação que participam normalmente do staking da Ethereum também devem manter algum poder, permitindo-lhes listar algumas transações que devem ser processadas.

Por exemplo, com uma parada de ônibus, um bloco pode ser entendido como um serviço com número limitado de assentos.

O Builder decide como a maioria dos passageiros fazem fila e onde sentam, visando aumentar a receita do trem por meio de um agendamento mais eficiente; no entanto, os nós de validação também podem apresentar uma “lista de passageiros obrigatórios”, e, desde que as transações na lista ainda sejam válidas, estejam dispostas a pagar taxas razoáveis e haja espaço suficiente no bloco, o Builder não pode rejeitá-las continuamente com base apenas em suas próprias preferências.

No entanto, ainda são dois problemas a serem resolvidos: quem deve criar a lista e o que fazer se alguém intencionalmente omitir uma transação.

FOCIL e FairFIL, exatamente nesses dois sentidos.

1. FOCIL: Não deixe mais um único Proposer criar uma lista de inclusão sozinho

FOCIL (Fork-Choice Enforced Inclusion Lists) transfere o poder de decidir quais transações devem ser incluídas do proponente único para um "comitê de validadores" composto por múltiplas partes.

Em cada ciclo de bloco, a rede seleciona aleatoriamente um grupo de nós de validação para formar um comitê temporário, e cada membro do comitê observa independentemente a mempool da rede e submete sua própria lista local.

Isso significa que, mesmo que 99% dos Builders e proponentes da rede tentem censurar uma determinada transação, desde que haja pelo menos um nó honesto na comissão que inclua essa transação na lista, ela terá a chance de ser incorporada ao protocolo. Se os censuradores quiserem continuar excluindo-a, não basterão mais influenciar uma única pessoa — precisarão contornar simultaneamente vários participantes independentes.

Então, sua vantagem é que não é necessário confiar em cada membro do comitê para manter a imparcialidade.

Mas apenas a lista não é suficiente; se o Builder receber a lista e ainda assim optar por não executar, a lista se tornará uma sugestão sem força obrigatória.

Portanto, o FOCIL adicionou um segundo nível de design, introduzindo uma regra de escolha de fork para impor restrições rígidas, fazendo com que os nós responsáveis por votar e validar na rede verifiquem estritamente os blocos enviados pelo Builder; caso seja detectado que o Builder violou a lista de inclusão integrada pelo comitê, toda a rede recusará diretamente votar no bloco.

Isso significa que blocos em violação serão imediatamente considerados inválidos pelo protocolo, e o Builder arcará com um alto custo de falha na geração de blocos.

2. FairFIL: Não basta apenas corrigir falhas, é preciso garantir que as omissões possam ser verificadas

Se FOCIL proíbe a censura rigidamente por meio de regras de consenso, então FairFIL (Fair Forward Inclusion Lists) e mecanismos de responsabilidade tornam a censura economicamente extremamente cara e insustentável.

Em outras palavras, ele impõe requisitos ainda mais rigorosos, como manter registros acessíveis para verificação pública sobre por que uma transação não entrou em um bloco.

Na operação real da rede, o Builder pode precisar de um período de buffer extremamente curto para otimizar a ordenação de transações e o arbitragem MEV. O FairFIL permite que o Builder faça ajustes de flexibilidade sob restrições específicas, mas se o Builder tentar prolongar qualquer comportamento de censura para o próximo bloco, o protocolo imediatamente inicia o processo de responsabilização.

Sua lógica geral pode ser compreendida em três etapas.

• Primeiro, o protocolo estabelecerá um conjunto de regras de referência públicas e verificáveis para determinar quais transações no pool público têm condições de entrar no bloco atual sob circunstâncias normais; se algumas transações que, conforme as regras de referência, originalmente tinham direito a entrar no bloco não forem processadas, o Builder deverá listá-las publicamente no FairFIL;
• Em seguida, os validadores verificarão se a lista está completa; se o Builder omitir transações elegíveis que deveriam estar na lista, essa ação poderá ser detectada e afetar a decisão dos nós validadores sobre apoiar ou não o bloco;
• Por fim, as transações válidas do FairFIL se tornarão tarefas prioritárias a serem processadas nos blocos subsequentes; o próximo Builder ainda pode determinar sua posição exata no bloco, mas não pode mais fingir que não as viu;

Se uma transação for continuamente omitida, o bloco relevante pode perder o suporte dos validadores, e o Builder também pode perder toda a receita do bloco.

Em outras palavras, a "responsabilização" enfatizada pelo FairFIL é na verdade alcançada por meio da introdução de penalidades econômicas em degraus, onde Builders que forem continuamente auditados correm o risco de perder toda a recompensa do bloco e até mesmo sofrer penalidades sobre seus depósitos de staking.

Este também é o rumo em que o mecanismo de resistência à censura da Ethereum está se aprofundando, visando estabelecer um conjunto de restrições mais realistas, de modo que, mesmo que poucos participantes tenham intenção de censurar, seja difícil controlar permanentemente a entrada de transações; mesmo que alguém intencionalmente omita transações, precisará deixar rastros e pagar um custo cada vez maior por censurar continuamente.

Para usuários comuns que realizam transferências, trocas ou utilizam DeFi diariamente por meio de carteiras, esses mecanismos subjacentes não exigirão alterações nos hábitos operacionais atuais, mesmo que sejam implementados no futuro.

O usuário ainda preenche o valor na carteira, confirma o Gas, conclui a assinatura e aguarda a confirmação da transação na cadeia, mas, na camada subjacente do protocolo, invisível ao usuário, a lógica que determina se a transação poderá entrar em um bloco pode sofrer mudanças importantes.

O que realmente melhora é a certeza do processo de inclusão da negociação.

• Primeiro, uma transação que atenda às regras não dependerá mais inteiramente da escolha de um determinado Builder: mesmo que o Builder atual não queira processá-la, outros validadores poderão, por meio de uma lista de inclusão, estabelecer um requisito de inclusão ao nível do protocolo;
• Em segundo lugar, o direito de incluir transações e o direito de ordenar transações podem gradualmente se separar: o Builder ainda poderá utilizar algoritmos profissionais para organizar a ordem das transações e aumentar os rendimentos dos blocos, e ainda poderá competir em torno de arbitragem e liquidação, mas seu poder de decidir «quem tem permissão para entrar no mercado» será limitado;

Olhando mais profundamente, a neutralidade confiável da Ethereum também pode evoluir de uma proposta de valor baseada no compromisso dos participantes para regras de protocolo executadas automaticamente pelos clientes.

Os usuários não precisam saber qual Builder construiu o bloco atual, nem precisam confiar individualmente em cada Builder para manter neutralidade ativa; os nós de validação verificarão os blocos conforme as mesmas regras, tornando difícil para blocos que violam as obrigações de inclusão serem reconhecidos pela rede.

No futuro, carteiras e block explorers podem até fornecer estados de transação ainda mais detalhados com base nisso.

Uma transação não é mais exibida apenas como “pendente”, mas pode informar ao usuário se já foi incluída na lista de inclusão, se possui obrigação de inclusão em blocos subsequentes, e se a continuação da espera se deve a gás insuficiente, transação expirada ou anomalia na construção do bloco.

No entanto, o mecanismo de resistência à censura não significa que cada transação será bem-sucedida imediatamente.

Transações com saldo insuficiente, conflito de Nonce, gas muito baixo ou condições de execução do contrato já expiradas ainda podem não ser incluídas em blocos; em casos de congestão da rede ou falta de espaço nos blocos, os usuários ainda precisam aguardar confirmação por meio de competição de taxas.

Mas o que ele melhora principalmente é uma transação que era originalmente válida, com taxas razoáveis e já propagada para o pool de transações público, e que não deveria ser adiada indefinidamente por escolhas subjetivas de poucos construtores de blocos.

Em termos de progresso, até agosto de 2026, o EIP-7805 correspondente ao FOCIL ainda está em estado de Draft, mas já foi selecionado pelos desenvolvedores principais da Ethereum como Headliner da camada de consenso da atualização Hegotá e entrou na fase Scheduled for Inclusion, o que significa que as equipes de clientes concordaram em avançar com a implementação e o desenvolvimento de testes de rede em torno dele, embora a data exata de lançamento na mainnet ainda não tenha sido finalizada.

FairFIL é mais antigo e, atualmente, é principalmente um projeto de pesquisa previsto para lançamento em julho de 2026. Se entrará ou não na rota da Ethereum ainda requer discussões mais amplas, implementação e validação de segurança.

Objetivamente, o Ethereum não pode garantir que todos os builders, validadores e operadores de infraestrutura permaneçam neutros para sempre.

Os participantes podem estar sujeitos a pressão regulatória, perseguir seus próprios interesses ou receber incentivos externos; uma rede descentralizada verdadeiramente resiliente não pode ser construída sobre o pressuposto ideal de que todos farão a coisa certa.

A verdadeira censura resistente significa que, mesmo que alguns participantes tentem interferir nas transações, outros ainda tenham a capacidade de quebrar esse controle; mesmo que alguém escolha se desviar dos princípios de neutralidade, o protocolo torna esse comportamento visível, caro e difícil de sustentar.

Da lista inicial de inclusão, ao FOCIL, onde o Builder é coletivamente regulado por um comitê distribuído, até o FairFIL, que exige que comportamentos de omissão possam ser verificados publicamente; da permissão para qualquer pessoa enviar transações à garantia de que as transações de qualquer pessoa tenham oportunidade de serem vistas.

Do ponto de vista deste aspecto, o Ethereum está realmente tentando transformar esse compromisso, passo a passo, de uma declaração de valor em algo incorporado diretamente no protocolo.

Worth looking forward to.