Nota dos Autores: init4é um coletivo de pesquisa que trabalha em ferramentas Ethereum de próxima geração. Esta é uma nota 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 descrevê-los como “vulnerabilidades” ou “anteriormente desconhecidos”.

A resistência à censura continua a ser um valor central das criptomoedas em geral e do Ethereum em particular. Acreditamos que os benefícios de realizar transações na cadeia devem estar disponíveis para todos, e que as regras da cadeia devem se aplicar a todos os usuários e usos igualmente. Os valores impulsionam esse espaço para a frente. Engenharia é o processo de testar nossos valores contra a realidade para encontrar onde e como eles se quebram.

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

Definindo Censura

Tendemos a modelar a censura como a prevenção intencional de transações de aparecerem na ordem canônica (ou seja, exclusão de transações). Consideramos as ordens como justas ou neutras quando dependem inteiramente do resultado econômico para o sistema de ordenação, e injustas ou censuradas quando dependem de outras informações. Por exemplo, ao criar um bloco, é aceitável recusar a inclusão de uma transação de baixa taxa, mas inaceitável recusar a inclusão de uma transação porque foi enviada por uma pessoa específica. Portanto, dizemos que uma transação é censurada se a sua inclusão depender de informações não econômicas. Se a transação cria mais lucro observável para o sistema de ordenação do que qualquer transação incluída, mas não é incluída, é 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 fundamental das cadeias OP Stack é que o Sequenciador 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 dada. Para mitigar isso, vários rollups - incluindo Otimismo e Arbitrum - 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 na L1. As transações de inclusão forçada, portanto, (teoricamente) têm a mesma resistência à censura que outras transações Ethereum.

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

Um mecanismo de inclusão forçada também foi proposto para o Ethereum via 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 bloco têm menos incentivos para censurar do que os construtores de bloco, isso forneceria uma mitigação efetiva à censura.

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

Expandindo Nosso Modelo de Resistência à Censura

Infelizmente, a confirmação da transação é o meio, não o fim. Nosso modelo de resistência à censura é incompleto!

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

Com isso em mente, devemos ampliar nossa definição de censura para dizer: uma transação é censurada se um terceiro pode impedi-la de alcançar seu objetivo. Ou seja, o censor não precisa evitar que a transação seja confirmada; eles só precisam fazer a execução do contrato inteligente reverter. Fazer uma transação EVM reverter é censura dessa transação, apesar de ela fazer 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 com a cadeia, há algum predicado de pontuação f que avalia a ordenação resultante e produz 0 (objetivo não alcançado) 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 inferi-lo. As negociações da Uniswap têm objetivos óbvios. Além disso, como as blockchains são determinísticas, o censor pode prever perfeitamente quais ordenações atenderão ao predicado do censor. Como resultado, os usuários não podem confiar em 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 trabalhando no modelo padrão de sequenciador run-ahead⁴. Lidaremos com a inclusão forçada sob rotação do 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 entre o conjunto de todas as ordens possíveis. Nossa questão semi-formal sobre resistência à censura então se torna "existe alguma ordem válida sobre a qual f avalia para 0"? Se tal ordem existe, então o sequenciador pode selecioná-la.

A partir daí, podemos expandir nosso modelo para considerar a inclusão forçada. "Existe alguma ordem válida, que inclui a subordenação do usuário, para a qual f avalia para 0?" Se tal ordem existir, o sequenciador pode selecioná-la. A inclusão forçada não impede o sequenciador de exercer controle sobre a ordem, apenas restringe seu comportamento. Infelizmente, a inclusão forçada tem questões fundamentais que a impedem de ser um mecanismo de resistência à censura eficaz para muitas transações.

O Problema da Entrega

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

Deve haver uma transição da inclusão voluntária para a inclusão forçada.

A transação forçada é executada no estado no momento da transferência. Então, mais uma vez, a contenção de estado⁵reaparece. Quando a transferência ocorre dentro de um lote de transações (como um bloco), o criador do lote pode exercer controle 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 resistência à censura.

Porque o criador do lote pode exercer controle sobre o estado na entrega, então pode afetar o resultado da transação forçada. Se pode afetar o resultado, pode potencialmente afetar o resultado do predicado de pontuação. Por exemplo, considere uma interação simples AMM. O usuário define um preço mínimo aceitável, no entanto, o criador do lote pode garantir que no ponto de 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 reverta, 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. Ela foi incluída na cadeia e nunca mais pode ser incluída novamente. 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 ser potencialmente 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, inicie uma mensagem do L2 para L1 para sacar fundos) diretamente a partir da camada 1. Assim, esse mecanismo preserva a resistência à censura mesmo que o Sequencer esteja completamente inoperante ou até mesmo malicioso.

• Arbitragem

No modelo de sequenciamento de antecipação, o sequenciador tem controle quase perfeito sobre a localização da entrega na sequência e paga taxas reduzidas (pois não precisam dar gorjeta e podem exercer algum controle sobre a taxa base EIP-1559). Como resultado, o sequenciador está em uma posição privilegiada para usar a contenção de estado para censurar ações do usuário. É trivial. O problema da entrega assegura que o sequenciador pode 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 transferência 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 em um estado no qual a transação reverterá, enquanto o sufixo restaurará a cadeia a um estado normal. As listas de inclusão EIP-7547 não são suficientes para evitar a censura para qualquer transação que acesse um estado controverso. O problema de transferência impede que as ILs 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 do blockchain. O problema de transferência garante que o censor tenha poder de decisão suficiente sobre o estado, mesmo que não tenha poder de decisão suficiente sobre a ordem. Esse problema afeta os 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 de estado cria limites difíceis 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 na Optimism. Quando o usuário deseja sacar USDC do mercado, eles enviam uma transação da Optimism, que o sequenciador censura. Eles então usam o mecanismo oficial de inclusão forçada para enfileirar sua transação no Ethereum, contornando o sequenciador.

O sequenciador pode ver essa transação na fila e pode optar por intercalá-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 reembolsar imediatamente o USDC.

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

Isso requer que o sequenciador tenha garantia suficiente para pegar emprestado o USDC, mas impõe apenas um custo de empréstimo extremamente baixo.¹⁰ Além disso, a garantia é reutilizável para toda a censura, já que o empréstimo nunca é mantido aberto. Como resultado, um usuário de AAVE ou Compound on Optimism (ou Arbitrum ou qualquer outro rollup sequenciado centralmente) não tem garantia de que será capaz de retirar garantias nunca. O sequenciador pode censurar qualquer retirada de qualquer mercado de empréstimos a qualquer momento. A inclusão forçada simplesmente não é suficiente para proteger os usuários contra a censura.

Trabalho de acompanhamento

Temos algumas áreas de pesquisa de acompanhamento.

Primeiro, o EIP-7547 pode ser facilmente melhorado exigindo que as transações IL sejam processadas no final do próximo bloco. No contexto do leilão da PBS, a resistência é MEV. O construtor obtém algum valor não econômico, ao qual ele deve atribuir um valor subjetivo denominado em ETH. A censura pelo construtor, portanto, causa 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 está 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 contenciosa. Por exemplo, censurar uma interação AMM via contenção de estado poderia exigir desistir de arbitragem AMM ou um alto custo para empurrar o mercado para fora da faixa que não pode ser recuperado fechando o sanduíche. Além disso, isso restringiria os pacotes de censura produzidos pelos Pesquisadores (em vez dos construtores) a um por bloco.¹²Nós recomendamos a execução no topo do bloco, já que o prefixo é mais significativo do que o sufixo, no entanto, isso aumentaria drasticamente o custo de uma transação de IL, pois permitiria a extração de MEV no topo do bloco por inclusão forçada.¹³Remover o direito do censor de pós-fixar atomicamente as transações do IL é uma pequena melhoria.

Em segundo lugar, o problema da transferência existe porque o censor pode antecipar via simulação de transações e exercer controle sobre o estado de entrada. Muitos mecanismos de resistência à MEV introduzem informações ocultas para remover a capacidade do censor de derivar informações sobre os objetivos dos usuários e simular resultados. Tipicamente, esses 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 informações ocultas 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 sequência de rollup. 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, aplicativos e o usuário final.

Em terceiro lugar, existe uma classe interessante de funções de pontuação "independentes de ordem". Estas são metas que não podem ser censuradas pela contenção do estado, seja porque não acessam estados controversos, ou porque o estado controverso que acessam tem restrições suficientes para torná-lo "confiável" de alguma forma. As ações independentes de ordem incluem enviar ETH para um EOA, a maioria dos envios ERC-20,¹⁴e algumas interações DeFi como adicionar garantia a um mercado. Estas ações estão protegidas contra censura via contenda. Esta classe de objetivos também tem correspondências interessantes na comunicação segura entre cadeias e resistência à MEV e merece um estudo mais aprofundado. Aplicações e protocolos podem ser projetados para incluir apenas ações independentes de ordem em alguns casos, mas mais estudo é necessário.

Conclusão

O estado rico permite que agentes mal-intencionados censurem transações enquanto ainda as incluem. O problema do hand-off é 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 as cadeias de Estado rico. 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 agradecerMike Neuder, Tarun Chitra, e Brandon Curtispara revisão e feedback.

1

Como é típico, para L1s isso é realizado rejeitando blocos inválidos, enquanto em rollups isso é realizado 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 disso neste momento.

3

Este é obviamente um modelo incompleto, pois não leva em consideração os valores subjetivos dos resultados. Por exemplo, o censor pode perder qualquer valor monetário se a censura falhar (por exemplo, porque podem ser presos pela polícia francesa se não conseguirem censurar determinados comportamentos). Por outro lado, o usuário pode ganhar/perder qualquer quantia de dinheiro se o seu objetivo não for alcançado dentro de um prazo específico (por exemplo, se eles tomaram empréstimos de mais de $100 milhões contra o seu próprio token e precisam re-colateralizar a posição antes de serem liquidados).

4

Ao contrário de um modelo sequenciador "baseado". Na maioria dos rollups modernos, o sequenciador "corre à frente" do Ethereum, pois fornece atestados de inclusão e execução para uma transação antes que a transação tenha sido comprometida com o Ethereum. Neste modelo, o Sequencer tem controle total sobre a sequência, e o resultado da transação deve ser independente das reorganizações Ethereum.

5

Quando vários usuários desejam acessar o mesmo contrato, ativo ou estado, suas transações "disputam" entre si e potencialmente interferem nos resultados uns dos outros. A disputa 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

Em geral, você deve pensar na censura via disputa estatal como um caso especial de MEV. Como o valor extraído é fora da cadeia, não observável e potencialmente muito grande, pode ser difícil prever quando ocorrerá a censura por meio de disputa de estado.

7

Especificamente abordamos o uso de contenção de estado para reverter transações em nosso artigo de 2017Miners Não São Seus Amigos”. Naquela época, o termo "MEV" ainda não estava em uso.

8

É sabido que a PBS complica drasticamente a resistência à censura. Veja VB's @vbuterin/pbs_censorship_resistance">nota de pesquisa.

9

Adicionar um prefixo e sufixo a uma transação é comumente chamado de 'sanduíche' e é bem compreendido como um método de usar a contenção de estado para extrair MEV.

10

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

11

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

12

Observe que isso se baseia nas regras de leilão MEV que impedem transações intercaladas de diferentes pacotes e não permitem transações "devem reverter". Se essas regras fossem relaxadas para permitir que txns de feixes fossem intercalados e/ou se os construtores começassem a suportar blocos "devem reverter" em pacotes, a proteção evaporaria. Essa dinâmica surge porque se as transações de 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 buscador pode ocorrer.

13

Permitindo efetivamente que o construtor crie pacotes limitados entre blocos. Sistemas pré-consenso como FOCILpode mitigar isso.

14

Para um token ERC-20 padrão, a chamada de transferência geralmente não pode ser censurada por meio de conflito, pois terceiros não podem diminuir o saldo do usuário. No entanto, considere uma chamada de transferFrom. Se o transferente aprovado for um contrato que permite conflito em seu próprio estado, então a ação pode ser censurada por meio desse conflito (consumindo a aprovação necessária para o transferFrom de alguma maneira não intencional).

Disclaimer:

1. Este artigo foi republicado a partir 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 Aprenda equipe, e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.