O caminho da Ethereum para a resistência à censura: BRAID vs. FOCIL

O caminho da Ethereum para a resistência à censura: BRAID vs. FOCIL

No cenário em evolução da Ethereum, a batalha pela resistência à censura introduziu vários mecanismos inovadores. Entre eles, BRAID e FOCIL se destacam como duas abordagens promissoras criadas para proteger a integridade da rede, minimizando o risco de censura de transações.

Ambas as soluções abordam questões críticas no processo de proposta de bloco, mas adotam abordagens fundamentalmente diferentes para atingir seus objetivos. Este artigo analisa as nuances desses dois mecanismos e explora qual deles pode se mostrar mais eficaz.

Entendendo a ameaça de censura na Ethereum

No centro do processo de geração e validação de blocos da Ethereum estão dois atores principais: construtores e proponentes. Os criadores são responsáveis por classificar as transações e enviar um bloco aos proponentes, que então selecionam um bloco para assinar e propor ao blockchain.

Esse processo, no entanto, cria uma vulnerabilidade em potencial. Como os proponentes têm a palavra final sobre qual bloco será proposto, há o risco de conluio entre proponentes e construtores para censurar determinadas transações, ameaçando assim o princípio de resistência à censura da Ethereum.

A resistência à censura é fundamental para manter a imparcialidade e a transparência do blockchain. Se os proponentes puderem incluir ou excluir transações seletivamente, isso prejudica a natureza descentralizada da rede e pode levar à exploração da ordenação de transações, resultando em problemas como o Miner Extractable Value (MEV).

Soluções existentes: MCP e FOCIL

Para enfrentar esse desafio, várias soluções resistentes à censura foram propostas, sendo que duas das mais discutidas são os mecanismos Force Inclusion List (FOCIL) e Multi-Concurrent Proposer (MCP).

Lista de inclusão de forças (FOCIL)

O FOCIL foi projetado para garantir a imparcialidade, envolvendo um comitê de validadores selecionados aleatoriamente durante cada intervalo de tempo.

Esses validadores criam listas de inclusão locais com base em suas visões do mempool e transmitem essas listas.

O proponente então agrega essas listas locais em uma lista de inclusão final que é adicionada ao bloco.

Esse mecanismo garante que nenhum proponente tenha controle total sobre as transações incluídas em um bloco, reduzindo assim o risco de censura.

Os validadores verificam se o bloco está de acordo com as regras de consenso antes de aceitá-lo no blockchain.

Proponente Multiconcorrente (MCP)

O MCP introduz o conceito de vários proponentes simultâneos, conforme sugerido pela primeira vez por Max Resnick no mecanismo de Multiplicidade.

Nesse sistema, vários proponentes trabalham em paralelo, cada um selecionando uma parte das transações do mempool.

Essas transações são agrupadas em “pacotes de transações especiais” e assinadas pelos proponentes. O proponente principal deve incluir pelo menos dois terços desses pacotes no bloco proposto para que ele seja considerado válido.

Esse método descentraliza o poder de um único proponente e reduz significativamente a probabilidade de censura da transação.

BRAID: Uma implementação aprimorada do MCP

Com base no conceito do MCP, Max Resnick desenvolveu o BRAID, uma implementação mais sofisticada e completa do MCP.

Apresentado durante o seminário “DeFi in MEV Era”, organizado pela Paradigm, o BRAID permite que vários proponentes proponham blocos em diferentes cadeias paralelas simultaneamente.

Esses blocos são então sincronizados por meio de um mecanismo de consenso para garantir a consistência entre as cadeias.

A camada de execução da Ethereum consolida todos os blocos gerados dentro do slot em um único bloco de execução, onde as transações são deduplicadas, ordenadas e executadas de acordo com regras predefinidas.

Essa abordagem reduz significativamente o poder de uma única entidade de manipular registros de transações.

Uma das principais vantagens do BRAID é o fato de evitar funções adicionais ou estruturas de incentivo complexas, que podem aumentar a complexidade.

MMC de BRAID

No entanto, coordenar a sincronização em várias subcadeias e lidar com o processamento de dados apresenta seus próprios desafios.

Desafios e considerações sobre o BRAID

Apesar de seus pontos fortes, a BRAID tem seus problemas. Um desafio notável é o modelo de “gorjeta condicional”, que exige que os usuários tenham liquidez disponível para garantir que suas transações sejam resistentes à censura. Os usuários devem definir dois valores de gorjeta ao enviar transações:

  1. Ponta mais alta (T): o valor máximo que um usuário está disposto a pagar para garantir que sua transação seja incluída, mesmo que haja tentativa de censura. Se apenas um proponente incluir a transação, ele receberá o valor total de T.
  2. Ponta inferior (t): Uma gorjeta menor que é paga se vários proponentes incluírem a transação. Nesse caso, a gorjeta é distribuída entre os proponentes que incluem a transação.

Esse modelo, embora eficaz para desestimular a censura, introduz complexidade e custos adicionais para os usuários. Eles precisam reservar liquidez extra no momento da transação, que pode ser congelada até que se determine se ela será necessária.

Para resolver esses problemas, Jonahb, da Blockchain Capital, sugere duas possíveis soluções:

  • Prova de liquidez pós-estatal: Essa abordagem permite que os usuários comprovem que terão liquidez suficiente para pagar a gorjeta mais alta depois que a transação for executada. No entanto, isso exige que os proponentes entendam o estado pós-transação, o que é um desafio em transações que envolvem estado compartilhado ou operações financeiras complexas.
  • Seguro contra censura: esse conceito introduz provedores de Seguro de Censura (CI) terceirizados que garantem a gorjeta do usuário em troca de uma taxa. Isso reduz a carga de liquidez imediata sobre os usuários, mas exige o desenvolvimento de um mercado entre os usuários e os provedores de CI.

Perspectivas da comunidade: FOCIL vs. BRAID

A comunidade Ethereum está dividida quanto aos méritos relativos do FOCIL e do BRAID. Terence, desenvolvedor do cliente Ethereum Prysm, aprecia o fato de o BRAID não exigir participantes adicionais, simplificando o processo em comparação com o FOCIL, que introduz restrições de tempo adicionais para o envio e a verificação das listas de inclusão. No entanto, o FOCIL é geralmente considerado mais fácil de implementar e mais flexível.

Dan Robinson, pesquisador da Paradigm, elogia a BRAID por sua abordagem de priorização de transações, reduzindo efetivamente os riscos de MEV. Ele também destaca o mecanismo de gorjeta condicional como um forte incentivo contra a censura – um aspecto que falta ao FOCIL.

Por outro lado, o desenvolvedor Dev favorece o FOCIL por sua simplicidade e resistência robusta à censura, sugerindo que o FOCIL oferece uma implementação mais direta com menos complicações.

O pesquisador do Ethereum barnabe.eth reconhece que, embora o BRAID possa oferecer melhorias em determinadas áreas, ele é cauteloso quanto ao abandono total do modelo baseado em líderes sobre o qual o FOCIL e outros projetos de IL são construídos, citando a necessidade de mais pesquisas e evidências para validar a viabilidade do BRAID.

Conclusão: Qual mecanismo é superior?

O debate entre BRAID e FOCIL ressalta a complexidade de se obter resistência à censura na Ethereum. A abordagem inovadora do BRAID para descentralizar o poder do proponente e reduzir o risco de MEV é convincente, mas apresenta desafios significativos de implementação e requer mais desenvolvimento.

O FOCIL, embora mais simples e flexível, pode não oferecer o mesmo nível de robustez contra tentativas sofisticadas de censura.

Em última análise, a escolha entre BRAID e FOCIL pode depender das prioridades específicas da rede Ethereum em um determinado momento. À medida que o ecossistema continua a evoluir, ambos os mecanismos podem desempenhar um papel no fortalecimento da resistência da Ethereum à censura, garantindo que a rede permaneça fiel aos seus princípios descentralizados.