No processo de produção e validação de blocos do Ethereum, os construtores são responsáveis ​​por ordenar as transações e enviar blocos aos proponentes por meio de um mecanismo de leilão. Os proponentes então selecionam um bloco para assinar e propô-lo à blockchain. Como os proponentes têm a palavra final como uma única entidade, há o risco de conluio entre proponentes e construtores para censurar transações.

Um dos valores centrais da blockchain é a sua resistência à censura, o que significa que as transações podem ser realizadas sem interferência de autoridades centrais. Quando os proponentes controlam quais transações são incluídas em um bloco, esse recurso é ameaçado, comprometendo a justiça e transparência. Além disso, esse poder pode ser explorado para manipular a ordem das transações em um bloco, levando a ganhos econômicos adicionais e levantando questões relacionadas ao Valor Extratível pelo Minerador (MEV).

Soluções existentes à prova de censura

Para enfrentar esse desafio, a comunidade propôs várias soluções anticensura, como as Listas de Inclusão Forçada (FOCILNo mecanismo FOCIL, um conjunto de validadores é selecionado aleatoriamente para cada slot, a fim de formar um comitê de listagem de inclusão. Esses membros do comitê geram listas de inclusão locais com base em sua visão subjetiva da mempool e as transmitem. Os proponentes são então responsáveis por coletar e agregar essas listas locais em uma única lista agregada a ser incluída no bloco. Esse mecanismo garante a justiça na inclusão de blocos, já que os validadores verificam a lista agregada em relação às listas locais transmitidas anteriormente, e apenas os blocos que atendem às regras de consenso são aceitos e adicionados à blockchain.

Além do FOCIL, a comunidade também discutiu o esquema de Múltiplos Proponentes Concorrentes (MCP). Este conceito foi inicialmente proposto porMax ResnicknoMultiplicidadeo Mecanismo de Multiplicidade, que visa dispersar o poder introduzindo múltiplos proponentes de bloco paralelos, reduzindo a capacidade de qualquer nó único para censurar transações. No Mecanismo de Multiplicidade, cada validador seleciona uma porção de transações de seu próprio mempool para formar um “pacote especial de transação”. Esses validadores assinam seus pacotes de transação escolhidos e os enviam para o proponente da rodada atual. O proponente deve incluir pelo menos 2/3 desses pacotes de transação no bloco que ele propõe para que seja considerado válido. Esse mecanismo garante que os proponentes não possam decidir unilateralmente o conteúdo do bloco, reduzindo assim a possibilidade de censura. Para incentivar ainda mais os proponentes a incluir transações de forma justa, esse mecanismo implementa uma regra de “dica condicional”, na qual apenas os proponentes que incluem a transação recebem as taxas de transação. As taxas de transação não são automaticamente dadas ao primeiro proponente que inclui a transação, mas são distribuídas a todos os proponentes que efetivamente incluem a transação com base em condições específicas. Isso aumenta o custo da censura, pois seria necessário subornar todos os proponentes que incluem a transação.

BRAID: Uma implementação MCP aprimorada

Com base no conceito de Multiplicidade, Max Resnick apresentou BRAID, uma implementação mais complexa e refinada do MCP. Max apresentouBRAIDno seminário "DeFi na era MEV" realizado pela Paradigm. BRAID alcança MCP permitindo que múltiplos proponentes proponham blocos em diferentes cadeias paralelas e usando um mecanismo de consenso de sincronização para manter consistência entre essas cadeias. Cada cadeia tem seu próprio proponente, e todos os proponentes lançam seus blocos simultaneamente dentro do mesmo slot. A camada de execução do Ethereum agrega os blocos gerados por todas as subcadeias dentro desse slot, formando um bloco de execução. Em seguida, ele deduplica, ordena e executa essas transações de acordo com regras pré-definidas, reduzindo a capacidade de qualquer entidade única manipular registros de transações.

O design da BRAID evita a introdução de papéis adicionais, evitando assim as complexidades associadas aos mecanismos de incentivo/punição. No entanto, sua implementação é relativamente complexa, exigindo a coordenação da sincronização e do processamento de dados de várias subcadeias.

Problemas com o mecanismo BRAID

Jonahbda equipe da Blockchain Capital apontou umproblema com o mecanismo BRAID: o modelo de "gorjeta condicional" impõe requisitos de liquidez, afetando a experiência do usuário. Esse modelo é uma estratégia de precificação dinâmica que exige que os usuários forneçam uma certa quantidade de liquidez para garantir a resistência à censura das transações. Ao enviar uma transação, os usuários devem definir dois valores de dica (T e t). A gorjeta real paga depende do número de proponentes que incluem a transação.

1. Um valor de gorjeta mais alto, T, representa a taxa máxima que um usuário está disposto a pagar para garantir que sua transação não seja censurada. O objetivo é incentivar os proponentes a incluir a transação mesmo se nenhum outro proponente estiver disposto a fazê-lo. Se apenas um proponente incluir a transação, ele receberá o valor total, T.
2. Um valor de gorjeta mais baixo, t, é o valor mínimo definido pelo usuário. Se a transação for incluída por vários proponentes simultaneamente, o usuário só precisa pagar t, que será compartilhado entre os proponentes. Se o usuário estiver menos preocupado com a resistência à censura, ele pode definir T igual a t e enviar sua transação para apenas um proponente.

No entanto, esse requisito adicional de liquidez aumenta a complexidade e o custo de participar em transações de blockchain. Os usuários precisam reservar fundos extras no momento da transação apenas para garantir sua resistência à censura. Esses fundos reservados permanecem congelados até que sejam realmente utilizados.

Para resolver esse problema, Jonahb propôs duas soluções:

• Prova de Liquidez Pós-Estado: Os usuários fornecem uma prova no momento da apresentação da transação, indicando que eles terão liquidez suficiente para pagar T após a execução da transação (por exemplo, o usuário terá $1M em liquidez após a transação). Esse método permite que os usuários prossigam mesmo se eles não tiverem fundos suficientes para pagar T antes da transação. O desafio com essa abordagem é que os proponentes precisam conhecer o estado final da transação antes da execução. No entanto, muitas transações financeiras envolvem estados compartilhados (como várias transações que afetam o mesmo saldo da conta), o que torna difícil para os proponentes determinarem com precisão o estado pós-transação antes que a ordem da transação seja finalizada. Essa abordagem requer provas personalizadas para cada tipo de transação, o que a torna menos prática.
• Seguro de Censura: Introduz provedores de seguro de censura de terceiros (provedores de CI) para garantir o T do usuário. Os usuários pagam um prêmio de seguro, rT, onde r é baseado na probabilidade de a transação ser censurada. Essa abordagem reduz a necessidade dos usuários de preparar imediatamente uma grande quantidade de liquidez e pode alertar os usuários se seu T estiver muito baixo e com alto risco de censura. No entanto, estabelecer um mercado entre usuários e provedores de CI leva tempo.

Pensamentos da Comunidade sobre FOCIL vs. BRAID

Desenvolvedor do cliente Ethereum PrysmTerence notasque uma vantagem significativa do BRAID é que não requer participantes adicionais. A maioria dos designs de Lista de Inclusão (IL), incluindo FOCIL, requer um participante extra, o que adiciona restrições de tempo dentro dos slots do Ethereum, como o tempo para enviar a IL, atualizar lances e validadores verificando a IL. No entanto, FOCIL é mais simples e flexível de implementar em comparação com o BRAID.

Pesquisador de paradigmasDan Robinson apreciaO design da BRAID para priorização de transações, que não é determinado por um único líder (proponente), assim mitigando efetivamente o MEV. Além disso, o mecanismo de gorjeta condicional da BRAID incentiva o comportamento de não censura, o que não está presente no FOCIL.

DesenvolvedorDev prefereFOCIL sobre MCP, acreditando que FOCIL oferece uma resistência mais forte à censura e é mais simples de implementar. Ele também sugere algumas melhorias para tornar o FOCIL mais fácil de implantar.

Pesquisador do Ethereumbarnabe.ethvisualizaçõesFOCIL como um mecanismo bastante geral e escalável. Ele reconhece que BRAID pode melhorar algumas das garantias fornecidas pelo FOCIL, mas é cauteloso em abandonar completamente o modelo baseado em líder. Ele acredita que mais trabalho é necessário para provar a viabilidade do BRAID.

declaração:

1. Este artigo é reproduzido de[Pesquisa ChainFeeds], o título original é “O caminho do Ethereum para resistência à censura: Quem é melhor, BRAID ou FOCIL?”, os direitos autorais pertencem ao autor original [0XNATALIE], se você tiver alguma objeção à reprodução, por favor entre em contatoEquipe de Aprendizado da GateA equipe irá cuidar disso o mais rápido possível de acordo com os procedimentos relevantes.

2. Aviso legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões do artigo são traduzidas pela equipe Gate Learn, não mencionadas emGate.io, o artigo traduzido não pode ser reproduzido, distribuído ou plagiado.