Wang Ye, Universidade de Macau: Ineficiência de Alocação, MEV e Transações Privadas em Blockchains Públicas

As transações privadas não podem eliminar completamente o risco de ser atacado nem reduzir as taxas de mercado.

Discurso: Wang Ye, Professor Auxiliar, Departamento de Ciências da Informação e Computação, Universidade de Macau

Compilação: aididiaojp.eth, Foresight News

*Este artigo é uma compilação de textos partilhados por Wang Ye, Professor Auxiliar do Departamento de Ciências da Informação e Computação da Universidade de Macau no Programa Young Scholars. O Programa para Jovens Acadêmicos é co-patrocinado por DRK Lab, imToken e Crytape. Jovens estudiosos bem conhecidos no campo da criptografia serão convidados a compartilhar alguns dos últimos resultados de pesquisa com a comunidade de língua chinesa. *

Antes de começar, deixe-me apresentar-me brevemente. Chamo-me Wang Ye. Trabalho actualmente como professor assistente no Departamento de Ciência da Informação e Computação da Universidade de Macau. A minha investigação actual centra-se em DeFi e áreas afins. Consideramos o DeFi como um mercado financeiro emergente e pesquisamos questões sob a perspectiva da economia e das finanças, incluindo a análise do comportamento do usuário e da estrutura do mercado. Além disso, também prestarei atenção aos possíveis problemas de segurança que existem durante o uso do usuário e como reduzir alguns perigos e problemas de segurança que aplicativos relacionados a Web3 e DeFi podem trazer, melhorando a experiência do usuário. O conteúdo que compartilho hoje está relacionado principalmente à primeira direção de pesquisa, ou seja, estudaremos alguns problemas de comportamento do usuário sob o novo modelo em um mercado financeiro descentralizado emergente e como podemos otimizar essa estrutura de mercado.

Esse mercado financeiro baseado no sistema blockchain terá alguns problemas endógenos, não conhecemos algumas soluções comuns no mercado e o impacto dessas soluções em todo o mercado. A seguir, apresentaremos como modelar os problemas atuais no mercado de blockchain do ponto de vista econômico ou financeiro após entender os problemas existentes e como usar o modelo para análise teórica. Na última parte, comparamos e analisamos os resultados da pesquisa teórica com os dados experimentais observados no mercado blockchain e, em seguida, provamos a aplicação de nossa derivação teórica no mercado real.

Todo mundo sabe que existem dois tipos diferentes de participantes no blockchain: um são os usuários comuns, o que eles fazem é enviar suas transações para toda a rede blockchain e, em seguida, esperar que suas transações sejam publicadas na rede. . O outro tipo é geralmente chamado de minerador, ou pode ser chamado de verificador no novo sistema, que vai coletar as transações enviadas por esses usuários na rede e formar um bloco. Quando tal bloco é transmitido e verificado pela maioria dos participantes do sistema, consideramos que todas as transações neste bloco foram confirmadas, ou completamente verificadas com sucesso. Nisso, descobriremos que existem vários problemas centrais que são muito diferentes do mercado financeiro tradicional. O primeiro problema é que as transações são transparentes até que sejam determinadas a serem executadas. Nos últimos dois anos, todo mundo propôs amplamente o conceito de Frontrunning. Na verdade, esse assunto não existe apenas no contexto das finanças descentralizadas, mas sempre existiu nas finanças tradicionais. Significa apenas que as finanças tradicionais podem ser usadas Algumas políticas ou regras e regulamentos eliminam completamente os riscos, mas no sistema blockchain, temos que ficar atentos a essa questão.

Quando uma transação é transmitida para a rede pública e antes de ser executada, ela já é observável por todos, o que envolve um problema gravíssimo de exposição a riscos. Em segundo lugar, a segunda questão muito crítica é sobre a ordem das transações.Atualmente, a maneira mais comum para os mineradores empacotar e classificar todas as transações é empacotá-las de acordo com o nível das taxas de processamento. Então isso trará um problema muito sério. Atualmente, as pessoas estão prestando cada vez mais atenção a questões relacionadas que não podem ser ignoradas no mercado financeiro descentralizado, ou seja, haverá um grande número de Running Attacks, ou podemos coletivamente consulte-os em muitos casos.Para MEV, Running Attack pode ser apenas uma parte do MEV.

Vamos descrever brevemente este processo novamente: quando encontramos uma transação, ela não foi executada. Qualquer um de nossos invasores pode usar informações conhecidas para criar uma nova transação e fornecer uma taxa de Gas mais alta para fazer com que a transação recém-enviada seja executada antes da transação vazada. Isso se deve aos problemas endógenos no sistema blockchain, que atualmente sempre existiram pelo menos no sistema blockchain público e são difíceis de proibir. Em seguida, vamos revisar alguns dos modos de ataque Frontrunning mais comuns.

O primeiro modo de ataque, acredito que muitos amigos podem estar familiarizados com ele, então vamos dar uma introdução mais clara aqui. Esse modo é chamado de Ataque Sanduíche. Seu ponto principal é que há um preço constante do criador de mercado do produto por meio do próprio mecanismo AMM. , antes que uma transação seja concluída, por meio de outra transação com antecedência para alterar a taxa de taxa de transação no mercado, depois que o comerciante vítima empurra ainda mais a taxa de transação para um resultado mais extremo, então por meio da transação reversa para obter Os fundos recebidos são trocados a um preço mais favorável, sendo os benefícios obtidos através da diferença cambial contida na operação. Em tal modo de ataque, podemos ver que quando há uma transação de vítima no mercado, essa transação geralmente é uma transação em AMM, e o invasor usará um valor mais alto antes da transação de vítima Gas fees para uma transação de execução antecipada. Terminada essa transação, eles usarão outra transação para realizar uma operação reversa e obterão benefícios através da diferença cambial entre a transação anterior e a subsequente. Isso é o que chamamos de primeiro tipo de Frontrunning.

O segundo tipo é o Ataque de Supressão mais comum. No mercado financeiro, o tempo é um fator muito importante. Muitas transações executadas um bloco depois e um bloco antes causarão grandes flutuações no mercado, principalmente quando consideramos que algumas transações podem envolver preços de liquidação. O principal alvo dessa classe de ataques são tais transações críticas. Por exemplo, esperamos que a transação possa ser executada no próximo bloco. Se um invasor mal-intencionado observar esta transação e, em seguida, expulsar a solicitação de transação de um bloco específico com uma transação que propõe uma taxa de gás mais alta, ela será atacada. pode esperar até o próximo ou os próximos blocos antes de ser executado. Devido à diferença de horário, podemos não conseguir concluir as operações de mercado de transações críticas a tempo, resultando em uma turbulência de mercado relativamente séria.

O terceiro ataque é chamado Displayment Attack, que é um ataque de arbitragem único. Você pode imaginar que quando estamos fazendo algumas transações cíclicas, os preços de mercado podem realmente ser diferentes. No entanto, a oportunidade especulativa potencial trazida pela diferença da taxa de câmbio é única. Se eu puder suavizar a diferença da taxa de câmbio no mercado por meio de transações repetidas, os invasores subsequentes não terão como especular para obter lucro. Então isso é voltado para esse tipo de oportunidade única de arbitragem. Assumimos que Tv é uma transação que obtém lucros por meio de transações de mercado. Depois que um invasor mal-intencionado observa Tv, ele pode realizar exatamente o mesmo comportamento de transação de mercado, mas a única diferença é que ele usará uma transação de arbitragem própria. taxa. Em seguida, ele será executado com antecedência no sistema blockchain real. Como ele executa primeiro a oportunidade de arbitragem única, a transação de TV em si não obterá mais benefícios.

Esses três são os ataques MEV nos quais estamos focando atualmente. Devido à configuração do mecanismo do sistema, a rede blockchain apresenta alguns problemas endógenos. Quando dizemos que o Frontrunning é muito comum, a próxima pergunta natural é se esse assunto é realmente sério e quanta perda de valor o MEV causará?

Temos uma estatística de que em menos de um ano, as perdas financeiras causadas por ataques de MEV no mercado ultrapassaram 80.000 Ethereum, o que significa que causou muitas perdas econômicas, e é por isso que todos prestarão atenção a esta questão , muitas pessoas também consideram como eliminar ataques MEV. Além de prestar atenção às perdas econômicas, também pensamos no impacto posterior de todo o incidente na rede blockchain, porque não apenas causou perdas econômicas, mas também desperdiçou uma certa quantidade de espaço em bloco.

Quando esse problema existe, todos devem estar constantemente pensando em como resolvê-lo. A solução atual é transmitir através do Private Pool, que costumava ser chamado de Relay Service. As transações não se propagam apenas por uma rede distribuída que os usuários expõem, elas fornecem um canal de comunicação privado que permite uma conexão direta entre usuários e mineradores. Através de tal canal de comunicação, você pode imaginar que a vantagem é que não teremos mais vazamento de informações. Como acreditamos que o Frontrunning também faz parte do MEV, esse pool privado é introduzido na rede na esperança de minimizar a aparência do Frontrunning.

Atualmente, o Frontrunning Attack é causado pelo vazamento de informações no sistema blockchain. Também sabemos que algumas pessoas propuseram alguns novos mecanismos para evitar essa situação. Portanto, se o novo mecanismo pode desempenhar um papel e que tipo de impacto terá no sistema blockchain, naturalmente se tornam as questões que queremos estudar.

Quando introduzirmos o Canal Privado no blockchain, que impacto isso terá em todo o ecossistema? Em primeiro lugar, será amplamente aceito pelos usuários e validadores de blocos? Porque eles são os principais participantes de todo o nosso sistema. Então, a segunda pergunta é se ele alcançou nosso objetivo desejado após ser aceito, que é reduzir as taxas de transação e evitar o Frontrunning. O terceiro ponto é depois que o novo mecanismo for introduzido, que tipo de impacto ele terá sobre todos os usuários em todo o sistema? Estas são as três questões de pesquisa que levantamos depois de descobrir possíveis soluções.

Construímos modelos para estudar e explicar o possível impacto de diferentes escolhas feitas por diferentes participantes no mercado e, finalmente, fazemos previsões, então comparamos e analisamos o comportamento do usuário do próprio mercado e nossos resultados de análise teórica. Então mostraremos aqui como dividir o problema em três estágios. Envolvemos três suposições diferentes em nosso modelo de três estágios. A primeira é que pensamos que os participantes são racionais, o que é uma suposição comum que fazemos em muitas pesquisas econômicas e financeiras. Em segundo lugar, pensaremos que algumas transações correrão o risco de serem atacadas, e haverá algumas transações que nunca serão atacadas no sistema. Ao mesmo tempo, construiremos um modelo baseado nos arbitradores ou atacantes que existem no este mercado.

Em todo o sistema, acreditamos que todas as transações têm dois canais de transação diferentes, um é nosso pool público de rede pública distribuída comum e o outro é o pool privado de rede privada. Finalmente, assumimos que cada bloco tem espaço suficiente para acomodar as transações. A seguir, em diferentes etapas desse modelo, cada usuário e cada verificador deve escolher uma das redes para transações. Em primeiro lugar, a primeira escolha é o verificador, a segunda é o usuário e a última é o invasor, o que está de acordo com nosso modo de operação normal no sistema de blocos. Depois que esses três participantes diferentes fazem suas escolhas, realizamos um cálculo reverso de qual estado o mercado inteiro eventualmente entrará.

Em primeiro lugar, os mineradores têm duas opções diferentes: a primeira opção é não ingressar no sistema Flashbots e a segunda opção é ingressar nele. Obviamente, essas duas opções sempre existirão para eles, se ficarem no canal público, só poderão ver as transações que existirem no Mempool público. Mas se eles entrarem no Private Pool, poderão ver não apenas as transações do Mempool, mas também as transações no Private Pool. Na primeira etapa do modelo, todos farão uma seleção, e então usamos alpha para indicar a proporção da seleção usando o flashbox.

A segunda parte é sobre a escolha do usuário em toda a transação. Eles escolherão propor suas próprias transações no Mempool ou escolherão propor no Private Pool? Se eles proporem transações no Mempool, correrão o risco de serem atacados. Eles também podem escolher Private Pool, mas existem certos riscos. A principal fonte desse risco é que essas transações que ingressam no Private Pool podem não ganhar 100% do direito de registrar o próximo bloco, mas podemos continuar a propor transações posteriormente.

O terceiro estágio é que o invasor observará as transações atacáveis e realizará as transações de ataque. Por exemplo, um invasor observa a transação P e decide atacar essa transação pública. Quando um invasor envia sua própria transação, ele também se depara com duas opções, no Public Pool ou no Flashbox. Se um invasor enviar uma transação no Pool Público, o invasor poderá fazer lances mais altos em várias rodadas, e o Gás de sua transação aumentará gradualmente. Esse é um modo de ataque comum em muitos casos. Se estiver no Private Pool, o invasor não sabe se há outros invasores competindo com ele ao mesmo tempo. Se no Public Pool, se outra pessoa competir com o ataque, os invasores podem realmente se conhecer. Mas no Private Pool, em primeiro lugar, o invasor não sabe se há concorrência e, em segundo lugar, não sei quanto de taxa de gás o concorrente pagou, então os invasores se tornam uma nova relação competitiva, o que os causará para fazer trocas. A taxa de gás que eles estão dispostos a pagar será realmente muito diferente. Se a transação do invasor for finalmente aceita, ele eventualmente terá um Lucro C, que também é a perda econômica causada.

Então é hora de balancear. A primeira é sobre usuários e invasores, a principal compensação que eles encontram é, na verdade, o risco operacional.

Os usuários precisam avaliar se minhas informações de transação vazarão ou se estou seguro, e o invasor não fornecerá suas informações de transação a outro invasor. Eles também correm o mesmo risco operacional, ou seja, os validadores do pool privado não têm 100% de direito de registrar o próximo bloco, portanto há uma grande probabilidade dessa transação não ser incluída no próximo bloco, mesmo que seja inútil para pagar taxas de gás suficientes.

Os usuários que não aderiram a Flashbots, precisam apenas classificar essas transações de acordo com a taxa de gás de alto a baixo, mas se ingressarem em Flashbots, devem primeiro classificar as transações propostas pelo Private Pool no bloco e depois verificar o resto do negócio. Por exemplo, a transação K é menor que a taxa de gás de suas transações anteriores e subsequentes, mas a transação K ainda é colocada na frente para verificação.

Depois que o catálogo de modelos hipotéticos for estabelecido, analisaremos gradualmente quais escolhas você fará a partir de três perspectivas. Primeiro conduzimos a análise comportamental da perspectiva do invasor. Os invasores naturalmente enfrentarão taxas de gás cada vez mais altas após passarem por uma competição contínua. Esta é uma conclusão central: descobriremos que o preço do gás que eles precisam enviar no pool privado é muito maior do que o preço do gás que eles precisam enviar no pool público preço. Mas muitos deles ainda escolherão o Private Pool. Há dois motivos principais. O primeiro motivo é que as transações de arbitragem que eles enviam no Private Pool não serão vistas por outros invasores e eles não precisam realizar lances, isso é um benefício . A segunda vantagem está na ordem de ordenação dos blocos, se for submetido através do Private Pool, sua prioridade é naturalmente maior do que as propostas pelo Public Pool. Neste caso, os atacantes irão naturalmente escolher Private Pool, mas ao mesmo tempo, para evitar o impacto de riscos operacionais, eles também irão negociar em alguns Public Pools ao mesmo tempo.

A próxima etapa é a compensação para os usuários. Eles considerarão principalmente dois fatores, um é a taxa de adoção e o outro é a probabilidade de possíveis ataques. Se a for relativamente grande, então você pode realmente imaginar que o risco operacional que eles enfrentam é relativamente pequeno e eles estarão naturalmente mais inclinados a usar o Private Pool. Se o alfa for muito pequeno, pode não ser útil para eles enviar no passado, então o Pool público se tornará sua escolha.

Também para a parte c, é realmente um fator muito importante. Descobrimos que, se C for grande o suficiente, eles não têm outra escolha a não ser propor uma transação no Private Pool. Se isso acontecer, podemos descobrir. Na verdade, as oportunidades de arbitragem para os invasores são completamente eliminadas.Se todos não usarem o Pool Público, esse assunto não existirá mais. Mas também temos que considerar um ponto: na verdade, na operação real, nem toda transação que causa MEV tem um espaço de arbitragem tão alto.

O que podemos ver agora é dizer muitos negócios que podem ser colocados no meio e talvez eles tenham apenas alguns dólares em troca. Depois que o invasor conclui o ataque, às vezes ele ainda precisa distribuir a maior parte dos lucros aos mineradores, e o incentivo restante pode ser inferior a US$ 1. Na verdade, há muitos casos em que C é muito pequeno. Nesse caso, eles não escolherão o Canal Privado, porque o Canal Privado não é uma escolha ideal para eles. A principal razão é que, para muitos usuários, eles não se importam se suas transações são atacadas ou não, eles estão dispostos a assumir o risco de serem atacados e sentem que correr riscos é pior para eles. Nesse caso, sabemos que se a taxa de adoção não for 100%, muitas transações devem ser atacadas.

Em seguida, para responder à segunda pergunta, a taxa de prioridade foi reduzida? Nossa conclusão final é que, mesmo depois de introduzirmos o Private Pool, a taxa de prioridade não será reduzida. Existem dois fatores principais aqui, a primeira parte, na verdade, como você pode imaginar, os verificadores vão optar por usar o Private Pool apenas quando receberem taxas mais altas, o que naturalmente aumenta a taxa de referência para entrar no bloco. Outro fator é que algumas pessoas podem estar vulneráveis a ataques, por isso não estão dispostas a escolher o Pool Público. Neste momento, elas preferem usar o Pool Privado para transações. Essas transações que não apareceriam no Pool Privado aumentarão ainda mais a prioridade taxa. A conclusão central final é que isso levou a um aumento nas taxas prioritárias.

A última questão central é se o valor geral dos blocos com os quais estamos preocupados aumentou? Podemos pensar sobre esse fator principal porque o Canal Privado não pode realmente atingir uma taxa de adoção de 100%, então ainda haverá muito Frontrunning, que ocupará nosso próprio espaço de bloco. Então, após a introdução, como esses Running Attacks que geram MEV não trazem realmente novos benefícios de rede para o sistema, eles obtêm uma parte das recompensas dos usuários atacados como seus próprios retornos especulativos, e não trarão alguns para o sistema. Novo valor, portanto, deste ponto de vista, mesmo depois de termos um Private Pool, ainda não conseguimos atingir o estado de alocação ideal e eficaz da rede. Ao mesmo tempo, devido à existência de MEV, em todo o sistema, quanto maior for o bem-estar geral da rede, a escolha mais benéfica para os verificadores não é. Nesse caso, a escolha dos mineradores também levará ao fato de que o bem-estar da rede do nosso sistema final não pode atingir uma solução ótima.

Em seguida, iremos mais longe para discutir se existem alguns métodos potenciais para nos ajudar a resolver tais problemas. O argumento central é que o retorno especulativo do invasor e a alocação ótima de recursos da rede são realmente incompatíveis. Os invasores precisam da geração de MEV para ajudá-los a aumentar sua taxa de retorno. De fato, um método possível é alterar a distribuição desigual do valor da rede, ou seja, fornecer um incentivo para que os invasores se envolvam em um método de participação na rede mais razoável e eficaz.

Por fim, gostaria de compartilhar brevemente com vocês alguns dados que obtivemos após análise teórica. Em primeiro lugar, olhamos para a taxa de aceitação de Flashbots. O que fazemos principalmente é ver se o bloco de transação é refletido intuitivamente por esta parte dos dados. Em seguida, descobrimos que a transação ainda está em tal estado no momento, nem todos Ninguém o viu, nem significa que todos possam vê-lo Esta é a nossa primeira conclusão. A segunda conclusão que chegamos é que a probabilidade de os usuários escolherem o Private Pool tem, na verdade, uma correlação positiva muito óbvia com a vulnerabilidade a ataques.

Na terceira parte, chegamos a uma conclusão relacionada ao tempo. Descobrimos que, em comparação com os atacantes no Mempool, os atacantes no Private Pool não precisam licitar rodada após rodada. Os atacantes que obtêm MEV, devem se submeter a As taxas do minerador são muito mais altas. No Public Pool, o payout ratio médio é de cerca de 0,3, mas no Flashbox ele subiu para perto de 0,8. Descobrimos que a probabilidade de escolher um Private Pool está, na verdade, positivamente correlacionada com o risco de ser atacado. Esta imagem é uma distribuição de probabilidade que você pode ver, e então descobrimos que quando a probabilidade de ser atacado aumenta em 1%, a preferência deles por escolher o pool privado aumentará em 0,6%.

Nossa primeira e principal conclusão é que seu Private Pool não pode eliminar completamente o risco de ser atacado, nem pode reduzir as taxas de mercado. Em segundo lugar, descobrimos que a introdução do Private Pool aumentará o bem-estar dos validadores e reduzirá o bem-estar dos invasores. O bem-estar geral da rede aumentará devido à alocação de espaço de bloco mais eficaz, mas não pode atingir o estado ideal.

Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
  • Recompensa
  • Comentário
  • Compartilhar
Comentário
0/400
Sem comentários
  • Marcar
Faça trade de criptomoedas em qualquer lugar e a qualquer hora
qrCode
Escaneie o código para baixar o app da Gate.io
Comunidade
Português (Brasil)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)