Nota dos autores: init4é um coletivo de pesquisa que trabalha em ferramentas Ethereum de próxima geração. Este é um documento de pesquisa, não um documento de divulgação. Embora discutamos nuances e lacunas nos modelos de segurança de sistemas implantados e propostos, seria hiperbólico descrever esses como "vulnerabilidades" ou "desconhecidos anteriormente".

A resistência à censura continua a ser um valor fundamental das criptomoedas em geral, e do Ethereum em particular. Acreditamos que os benefícios de realizar transações on-chain devem estar disponíveis para todos e que as regras da cadeia devem aplicar-se a todos os utilizadores e usos de forma igual. Os valores impulsionam este espaço para a frente. A engenharia é o processo de testar os nossos valores contra a realidade para descobrir onde e como eles falham.

Dominós também seguem uma sequência :) Foto por Tom WilsonemUnsplash

Definindo Resistência à Censura

Tendemos a modelar a censura como impedindo intencionalmente que as transações apareçam na ordem canônica (ou seja, exclusão de transações). Consideramos as ordens justas ou neutras quando dependem inteiramente do resultado económico do sistema de ordenação e injustas ou censuradas quando dependem de outras informações. Por exemplo, ao criar um bloco, é aceitável recusar-se a incluir uma transação de taxa baixa, mas inaceitável recusar-se a incluir uma transação porque foi enviada por uma pessoa específica. Portanto, dizemos que uma transação é censurada se sua inclusão depender de informações não econômicas. Se a transação cria mais lucro observável para o sistema de pedidos do que qualquer transação incluída, mas não está incluída, ela é considerada censurada. Esta definição motiva o trabalho sobre mecanismos de inclusão forçada para resistência à censura. Se um usuário pode forçar a inclusão de sua transação, então ela não pode ser censurada sob esta definição.

Mecanismos de Inclusão Forçada

Um objetivo de segurança central das cadeias OP Stack é que o Sequencer não deve ser capaz de impedir os usuários de enviar transações para a cadeia L2.

• Otismo

Os rollups modernos tendem a ter sequenciamento centralizado. Isso significa que a censura pelo sequenciador é trivial, pois eles podem simplesmente optar por não incluir qualquer transação de usuário fornecida. Para mitigar isso, vários rollups - incluindo OptimismoeArbitrum - têm mecanismos de inclusão forçada. Esses mecanismos permitem que um usuário garanta que sua transação será executada pelo rollup após algum atraso de tempo, independentemente do comportamento do sequenciador. A inclusão é forçada por meio de um contrato implantado no L1. Portanto, as transações de inclusão forçada têm (teoricamente) a mesma resistência à censura que outras transações Ethereum.

A inclusão forçada especifica o subintervalo que deve ser preservado em qualquer ordenação válida.

Também foi proposto um mecanismo de inclusão forçada para o Ethereum através do Gate.EIP-7547. As listas de inclusão permitiriam que as propostas de bloco especificassem parcialmente o conteúdo do próximo bloco. Sob a suposição de que os proponentes de blocos têm menos incentivos para censurar do que os construtores de blocos, isso proporcionaria uma eficaz mitigação à censura.

De um modo geral, mecanismos de inclusão forçada criam novas restrições nas ordens válidas. Eles tornam amplas classes de ordens inválidas de acordo com as regras do protocolo.¹A inclusão forçada deve ser considerada como permitindo que o usuário especifique um subconjunto da ordenação futura. Todas as ordenações válidas devem expandir o subconjunto forçado.

Expandindo o Nosso Modelo de Resistência à Censura

Infelizmente, a confirmação da transação é o meio, não o fim. Nosso modelo de censura está incompleto!

A censura deve ser definida em termos de objetivos. Os utilizadores querem enviar tokens, comprar NFTs, pedir empréstimos, etc. A confirmação da transação é incidental a esse objetivo²Os censores, da mesma forma, têm objetivos específicos. Esse objetivo pode ser evitar que alguma transação de hack tenha sucesso, cumprir alguma lei ou interferir no negócio de um concorrente. Respeitando a intenção de ambas as partes, precisamos redefinir a censura.

Tendo isso em mente, devemos expandir nossa definição de censura para dizer: uma transação é censurada se um terceiro puder impedi-la de alcançar seu objetivo. Ou seja, o censor não precisa impedir que a transação seja confirmada; eles só precisam fazer com que a execução do contrato inteligente seja revertida. Fazer com que uma transação EVM seja revertida é uma forma de censura dessa transação, mesmo que ela faça parte da cadeia canônica. Modelos de ameaça que são cegos para o conteúdo de uma transação não modelam com precisão a censura e, portanto, não podem proteger efetivamente os usuários dela.

Semi-formalmente, diríamos que para qualquer interação dada com a cadeia, existe algum predicado de pontuação f que avalia a ordem resultante e produz 0 (objetivo falhou) ou 1 (objetivo alcançado). Neste modelo, a função de pontuação do censor é simplesmente a negação: f’ = !f. O censor alcança seu objetivo quando o usuário não o faz.³

Embora o objetivo do usuário possa estar oculto, a própria transação quase sempre contém informações suficientes para inferir isso. As negociações na Uniswap têm objetivos óbvios. Além disso, como as blockchains são determinísticas, o censor pode prever perfeitamente quais ordenações satisfarão o predicado do censor. Como resultado, os usuários não podem contar com informações ocultas para protegê-los da censura no modelo EVM. Os detalhes da transação devem ser públicos, o que significa que as informações sobre o objetivo do usuário são públicas.

Para simplificar, vamos supor que estamos a trabalhar no modelo padrão de sequenciador run-ahead.⁴Trataremos da inclusão forçada sob rotação de sequenciador mais tarde. Neste modelo, o sequenciador tem controle total sobre a sequência e pode simular perfeitamente qualquer resultado. Ou seja, eles são livres para escolher dentre o conjunto de todas as possíveis ordenações. Nossa pergunta semi-formal sobre censura então se torna 'existe alguma ordenação válida sobre a qual f avalia para 0'? Se tal ordenação existir, então o sequenciador pode selecioná-la.

A partir daí, podemos expandir o nosso modelo para incluir a inclusão forçada. 'Existe alguma ordenação válida, que inclua a sub-ordenção do utilizador, para a qual f avalia a 0?' Se tal ordenação existir, o sequenciador pode selecioná-la. A inclusão forçada não impede o sequenciador de exercer controlo sobre a ordenação, apenas restringe o seu comportamento. Infelizmente, a inclusão forçada tem problemas fundamentais que impedem que seja um mecanismo eficaz de resistência à censura para muitas transações.

O Problema da Transferência

Mecanismos de inclusão forçada significam que a ordenação ocorre em um dos dois modos: não forçado ou forçado. Existe um ponto definido em que ocorre a transição de não forçado para forçado (e vice-versa). Esse ponto é a entrega. A entrega apresenta um problema complicado para o design de mecanismos de inclusão forçada.

Deve haver uma transição de inclusão não forçada para inclusão forçada.

A transação forçada é executada no estado na entrega. Portanto, mais uma vez, a disputa de estado⁵a resistência à censura mostra a sua cara feia. Quando a transferência ocorre dentro de um lote de transações (como um bloco), o criador do lote pode exercer controlo sobre o estado na transferência. Se a transação de inclusão forçada ler algum estado público, então o criador do lote pode reescrever esse estado antes e depois da execução da transação forçada. A contenção é suficiente para a censura.

Como o criador do lote pode exercer controle sobre o estado na entrega, então ele pode afetar o resultado da transação forçada. Se ele pode afetar o resultado, ele pode potencialmente afetar o resultado do predicado de pontuação. Por exemplo, considere uma interação AMM simples. O usuário define um preço mínimo aceitável, no entanto, o criador do lote pode garantir que no momento da entrega o preço de mercado esteja abaixo do preço mínimo aceitável. Isso faz com que a transação do usuário seja revertida, efetivamente censurando o usuário.⁶⁷

Curiosamente, a censura via contenda estatal é mais eficaz do que a censura via exclusão. Uma transação excluída pode ser incluída em blocos futuros. Uma transação censurada via contenda é permanentemente invalidada. Foi incluída na cadeia e nunca mais pode ser incluída. Essa transação nunca pode alcançar o objetivo do usuário. Para tentar novamente, o usuário deve recriar e reenviar a transação (que então pode potencialmente ser censurada novamente).

Em sistemas práticos

[Qualquer] usuário pode contornar completamente o Sequencer para enviar qualquer transação do Arbitrum (incluindo uma que, por exemplo, inicia uma mensagem de L2 para L1 para sacar fundos) diretamente da camada 1. Assim, esse mecanismo preserva a resistência à censura mesmo que o Sequencer esteja completamente irresponsivo ou até mesmo malicioso.

• Arbitrum

No modelo de sequenciamento antecipado, o sequenciador tem um controle quase perfeito sobre a localização da transferência na sequência e paga taxas reduzidas (pois não precisa dar gorjeta e pode exercer algum controle sobre a base de taxas EIP-1559). Como resultado, o sequenciador está em uma posição privilegiada para usar a contenda de estado para censurar ações do usuário. É trivial. O problema da transferência garante que o sequenciador possa censurar grandes classes de transações.

Para EIP-7547, os construtores escolhem onde ocorrem as transferências de blocos.⁸Como resultado, o construtor é capaz de escolher a localização da entrega dentro do bloco. Isso significa que eles podem selecionar um prefixo e um sufixo à vontade,⁹desde que respeitem as regras de gás de bloco. O prefixo pode colocar a cadeia num estado em que a transação irá reverter, enquanto o sufixo restaurará a cadeia a um estado normal. As listas de inclusão do EIP-7547 não são suficientes para prevenir a censura para qualquer transação que aceda a um estado controverso. O problema de entrega impede que as LI garantam a execução da transação na maioria dos casos.

A inclusão forçada é ineficaz na proteção dos usuários contra a censura na maioria dos usos não triviais da blockchain. O problema de transferência de responsabilidade garante que o censor tenha poder discricionário suficiente sobre o estado, mesmo que não tenham poder discricionário suficiente sobre a ordem. Esse problema afeta AMMs, mercados de empréstimos, leilões e a maioria das outras ações DeFi. Muitas ações importantes são passíveis de censura, mesmo que você possa garantir a inclusão da transação. A contenção do estado cria limites rígidos na eficácia da inclusão forçada como mecanismo de resistência à censura.

Estudo de caso

Para ver os efeitos de longo alcance disso, considere um usuário emprestando USDC em um mercado de empréstimos no Optimism. Quando o usuário quer retirar USDC do mercado, ele envia uma transação Optimism, que o sequenciador censura. Eles então usam o mecanismo oficial de inclusão forçada para enfileirar sua transação no Ethereum, ignorando o sequenciador.

O sequenciador pode ver essa transação na fila e pode escolher sanduícheá-la. Para censurar a transação, o sequenciador toma emprestado todo o USDC disponível do mercado imediatamente antes da transação forçada. Como o mercado não tem mais liquidez, a transação forçada é revertida. O sequenciador pode então pagar o USDC imediatamente.

O sequenciador ou construtor pode manipular o estado na transferência.

Isto requer que o sequenciador tenha colateral suficiente para emprestar o USDC, mas impõe apenas um custo de empréstimo extremamente pequeno.¹⁰Além disso, o colateral é reutilizável para todas as formas de resistência à censura, pois o empréstimo nunca é mantido em aberto. Como resultado, um usuário do AAVE ou Compound na Optimism (ou Arbitrum ou qualquer outro rollup sequencialmente centralizado) não tem garantia de que poderá retirar o colateral. O sequenciador pode censurar qualquer retirada de qualquer mercado de empréstimo a qualquer momento. A inclusão forçada simplesmente não é suficiente para proteger os usuários contra a censura.

Trabalhos de acompanhamento

Temos algumas áreas de pesquisa de acompanhamento.

Em primeiro lugar, o EIP-7547 pode ser melhorado de forma trivial, exigindo que as transações IL sejam processadas no final do próximo bloco. No contexto do leilão PBS, a resistência à censura é MEV. O construtor deriva algum valor não econômico, ao qual deve atribuir um valor subjetivo denominado em ETH. A censura pelo construtor causa, portanto, um aumento no lance do bloco do construtor.¹¹Isso se estende aos pesquisadores, que podem criar pacotes de censura. Parte do valor econômico da censura é então capturada pelo proponente, fornecendo um incentivo para tolerar a censura mesmo quando não estiver participando diretamente. Colocar transações de inclusão forçada no final do bloco remove a capacidade do construtor de bloco de trivialmente intercalar as transações IL, e aumenta o custo econômico da censura controversa. Por exemplo, censurar uma interação AMM via contenda de estado poderia exigir desistir de alguma arbitragem de AMM ou um alto custo para empurrar o mercado para fora do alcance que não pode ser recuperado fechando o intercalado. Além disso, isso restringiria os pacotes de censura produzidos por Pesquisadores (em vez de construtores) a um por bloco.¹²Recomendamos a execução no topo do bloco, uma vez que o prefixo é mais significativo do que o sufixo, no entanto, isso aumentaria drasticamente o custo de uma transação IL, uma vez que permitiria a extração de MEV no topo do bloco através da inclusão forçada.¹³Remover o direito do censor de adicionar atomicamente pós-fixo às transações IL é uma pequena melhoria.

Em segundo lugar, o problema da transferência existe porque o censor pode antecipar através da simulação de transações e exercer controle sobre o estado de entrada. Muitos mecanismos de resistência ao MEV introduzem informações ocultas para remover a capacidade do censor de derivar informações sobre os objetivos dos usuários e simular resultados. Normalmente, estes são esquemas de compromisso-revelação, onde algumas informações de transação são privadas até depois da ordenação ocorrer. A separação entre ordenação e execução e a informação oculta parecem promissoras, mas são em grande parte incompatíveis com a cadeia de suprimento de MEV, os processos de consenso do Ethereum e o modelo de rollup sequenciado. Alguma forma de neGate a capacidade de simular transações abordaria a censura e grandes classes de MEV, mas seria extremamente invasiva para o protocolo, os operadores do protocolo, as aplicações e o usuário final.

Terceiro, há uma classe interessante de funções de pontuação “independentes da ordem”. Estes são objetivos que não podem ser censurados pela contenção do estado, quer porque não acedem a um estado conflituoso, quer porque o estado conflituoso a que acedem tem restrições suficientes para o tornar “fiável” de alguma forma. As ações independentes da ordem incluem o envio de ETH para um EOA, a maioria dos envios de ERC-20,¹⁴ e algumas interações DeFi, como adicionar garantia a um mercado. Essas ações são protegidas contra censura por meio de contenção. Essa classe de objetivos também tem correspondências interessantes em comunicação segura entre cadeias e resistência a MEV e vale a pena um estudo mais aprofundado. Aplicativos e protocolos podem ser projetados para incluir apenas ações independentes de ordem em alguns casos, mas mais estudos são necessários.

Conclusão

O estado avançado permite que atores mal-intencionados censurem transações enquanto ainda as incluem. O problema da transferência é fundamental para os mecanismos de inclusão forçada e só pode ser resolvido. Em rollups sequenciados centralmente, nenhuma mitigação é possível. A inclusão forçada não pode abordar a censura na presença de um Estado contencioso. Grandes classes de transações economicamente importantes podem ser censuradas, mesmo que incluídas pela força. O problema do hand-off é endêmico nos rollups modernos e está presente nos EIPs de resistência à censura do Ethereum. Como resultado, a inclusão forçada, embora benéfica, nunca é suficiente para fornecer resistência à censura para cadeias de estados ricos. Os rollups não "herdam" as propriedades de segurança do Ethereum e é bobo sugerir que sim. Quando você para de ficar obcecado com a inclusão, torna-se óbvio que a resistência à censura é um caso especial de resistência ao MEV.

Gostaríamos de agradecer Mike Neuder, Tarun Chitra, e Brandon Curtis para revisão e feedback.

1

Como é típico, para L1s isso é feito rejeitando blocos inválidos, enquanto em rollups isso é feito coagindo sequências inválidas a sequências válidas por meio de alguma função de filtragem.

2

Este não é um post sobre intenções, o mundo não precisa de mais dessas neste momento.

3

Este é, obviamente, um modelo incompleto, pois não leva em conta os valores subjetivos dos resultados. Por exemplo, o censor pode perder qualquer quantia de dinheiro se a censura falhar (por exemplo, porque pode ser preso pela polícia francesa se não censurar determinado comportamento). Por outro lado, o usuário pode ganhar / perder qualquer quantidade de dinheiro se seu objetivo não for alcançado em um período de tempo específico (por exemplo, eles tomaram US $ 100 mm + em empréstimos contra seu próprio token e precisam garantir novamente a posição antes de serem liquidados).

4

Ao contrário de um modelo de sequenciador “baseado”. Na maioria dos rollups modernos, o sequenciador “avança” o Ethereum, pois fornece inclusão e atestações de execução para uma transação antes que a transação tenha sido confirmada no Ethereum. Neste modelo, o Sequenciador tem controle total sobre a sequência, e o resultado da transação deve ser independente de reorganizações do Ethereum.

5

Quando vários usuários querem acessar o mesmo contrato, ativo ou estado, suas transações "disputam" entre si e potencialmente interferem nos resultados uns dos outros. A discórdia pode surgir por coincidência ou deliberadamente. Este é um problema intratável de estado rico em sistemas blockchain. O acesso público ao Estado compartilhado é a raiz do MEV, dos problemas de escalabilidade e do declínio da civilidade na sociedade moderna.

6

Geralmente, você deve pensar na censura via contenção estatal como um caso especializado de MEV. Como o valor extraído é off-chain, não observável e potencialmente muito grande, pode ser difícil prever quando ocorrerá a censura via contenção estatal.

7

Especificamente abordamos o uso da contenda do estado para reverter transações no nosso artigo de 2017Os mineradores não são seus amigosNaquela época, o termo "MEV" ainda não estava em uso.

8

É sabido que a PBS complica dramaticamente a resistência à censura. Ver VB's @vbuterin/pbs_censorship_resistance">Nota de pesquisa.

9

Prefixar e sufixar uma transação é comumente chamado de 'sanduichar' e é bem compreendido como um método de usar a contenção de estado para extrair MEV.

10

O empréstimo é mantido por apenas alguns segundos, se tanto. Os sequenciadores rollup podem, em alguns casos, manter carimbos de data/hora ou limites de bloco para tornar o tempo efetivo de empréstimo 0.

11

O construtor estará disposto a pagar até o seu valor subjetivo de censura, potencialmente empurrando a oferta acima do valor extraível objetivamente observável do bloco. Em casos extremos, isso pode resultar em casos em que o censor tem uma mudança de saldo ETH negativa (ou seja, eles pagam mais ETH para produzir o bloco do que recebem em taxas e recompensas).

12

Observe que isso depende das regras de leilão MEV que impedem transações de intercalação de pacotes diferentes e não permitem transações "deve reverter". Se essas regras fossem relaxadas para permitir que txns de pacote fossem intercaladas e/ou se os construtores começassem a suportar blocos "deve reverter" em pacotes, a proteção evaporaria. Essa dinâmica surge porque se as transações IL devem estar no final do bloco, nenhuma transação não forçada pode ser intercalada e, portanto, no máximo um pacote de censura de pesquisador pode ocorrer.

13

Permitindo efetivamente que o construtor crie pacotes limitados entre blocos. Sistemas pré-consenso como FOCIL poderia mitiGate isso.

14

Para um token ERC-20 padrão, a chamada de transferência geralmente não é resistente à censura através de contenção, pois terceiros não podem diminuir o saldo do usuário. No entanto, considere uma chamada transferFrom. Se o transferidor aprovado for um contrato que permite a contenção em seu próprio estado, então a ação pode ser passível de censura por meio dessa contenção (consumindo a aprovação necessária para o transferFrom de forma não intencional).

Aviso legal：

1. Este artigo é reimpresso de [a tecnologia], Todos os direitos autorais pertencem ao autor original [init4]. Se houver objeções a este reenvio, entre em contato com o Gate Aprenderequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.