Wang Ye, Universidad de Macao: Ineficiencia en la asignación, MEV y transacciones privadas en cadenas de bloques públicas

Las transacciones privadas no pueden eliminar por completo el riesgo de ser atacado ni reducir las tarifas del mercado.

Discurso: Wang Ye, Profesor Asistente, Departamento de Ciencias de la Información y Computación, Universidad de Macao

Compilación: aididiaojp.eth, Foresight News

*Este artículo es una compilación de textos compartidos por Wang Ye, Profesor Asistente del Departamento de Ciencias de la Información y Computación de la Universidad de Macao en el Programa de Jóvenes Académicos. El Programa de jóvenes académicos está copatrocinado por DRK Lab, imToken y Crytape. Se invitará a jóvenes académicos de renombre en el campo de la encriptación a compartir algunos de los últimos resultados de investigación con la comunidad de habla china. *

Antes de comenzar, permítanme presentarme brevemente. Soy Wang Ye. Actualmente trabajo como profesor asistente en el Departamento de Ciencias de la Información y la Computación de la Universidad de Macao. Mi investigación actual se centra en DeFi y campos relacionados. Consideramos a DeFi como un mercado financiero emergente e investigamos temas desde la perspectiva de la economía y las finanzas, incluido el análisis del comportamiento del usuario y la estructura del mercado. Además, también prestaré atención a los posibles problemas de seguridad que existen durante el uso del usuario y cómo reducir algunos peligros y problemas de seguridad que Web3 y las aplicaciones relacionadas con DeFi pueden generar al mejorar la experiencia del usuario. El contenido que comparto hoy está relacionado principalmente con la primera dirección de investigación, es decir, estudiaremos algunos problemas de comportamiento de los usuarios bajo el nuevo modelo en un mercado financiero descentralizado emergente y cómo podemos optimizar dicha estructura de mercado.

Tal mercado financiero basado en el sistema blockchain tendrá algunos problemas endógenos. No conocemos algunas soluciones comunes en el mercado y el impacto de estas soluciones en todo el mercado. A continuación, presentaremos cómo modelar los problemas actuales en el mercado de blockchain desde la perspectiva de la economía o las finanzas después de comprender los problemas existentes y cómo usar el modelo para el análisis teórico. En la última parte, comparamos y analizamos los resultados de la investigación teórica con los datos experimentales observados en el mercado de blockchain y luego probamos la aplicación de nuestra derivación teórica en el mercado real.

Todo el mundo sabe que hay dos tipos diferentes de participantes en la cadena de bloques: uno son los usuarios comunes, lo que hacen es enviar sus transacciones a toda la red de la cadena de bloques y luego esperar que sus transacciones se publiquen en la red que se ejecuta en el sistema. . El otro tipo generalmente se denomina minero, o puede llamarse verificador en el nuevo sistema, recogerá las transacciones enviadas por estos usuarios en la red y formará un bloque. Cuando dicho bloque es transmitido y verificado por la mayoría de los participantes del sistema, consideramos que todas las transacciones en este bloque han sido confirmadas o completamente verificadas con éxito. En esto, encontraremos que hay varios problemas centrales que son muy diferentes del mercado financiero tradicional. El primer problema es que las transacciones son transparentes hasta que se determina su ejecución y ejecución. En los últimos dos años más o menos, todo el mundo ha propuesto ampliamente el concepto de Frontrunning. De hecho, este asunto no solo existe en el contexto de las finanzas descentralizadas, sino que siempre ha existido en las finanzas tradicionales. Solo significa que las finanzas tradicionales se pueden utilizar Algunas políticas o reglas y regulaciones eliminan por completo los riesgos, pero en el sistema blockchain, debemos prestar atención a este problema.

Cuando una transacción se transmite a la red pública y antes de que se ejecute, ya es observable por todos, lo que implica un problema de exposición al riesgo muy grave. En segundo lugar, el segundo tema muy crítico es sobre el orden de las transacciones. En la actualidad, la forma más común para que los mineros empaqueten y clasifiquen todas las transacciones es empaquetarlas en orden de acuerdo con el nivel de las tarifas de manejo. Entonces esto traerá un problema muy serio. En la actualidad, las personas están prestando cada vez más atención a los problemas relacionados que no se pueden ignorar en el mercado financiero descentralizado, es decir, habrá una gran cantidad de Running Attacks, o podemos colectivamente referirse a ellos en muchos casos Para MEV, Running Attack puede ser solo una parte de MEV.

Describamos brevemente este proceso nuevamente, cuando encontramos una transacción, no ha sido ejecutada. Cualquiera de nuestros atacantes puede usar información conocida para crear una nueva transacción y proporcionar una tarifa de gas más alta para que la transacción recién enviada se ejecute antes de la transacción filtrada. Esto se debe a los problemas endógenos en el sistema blockchain, que en la actualidad siempre han existido al menos en el sistema blockchain público y son difíciles de prohibir. A continuación, repasemos algunos de los modos de ataque Frontrunning más comunes.

El primer modo de ataque, creo que muchos amigos pueden estar familiarizados con él, así que vamos a dar una introducción más clara aquí. Este modo se llama Sandwich Attack. Su punto central es que hay un precio constante de creador de mercado de productos a través del propio mecanismo AMM. , antes de que se complete una transacción, a través de otra transacción por adelantado para cambiar la tarifa de la tarifa de transacción en el mercado, luego, después de que el comerciante víctima empuje aún más la tarifa de transacción a un resultado más extremo, luego a través de la transacción inversa para obtener Los fondos recibidos se intercambian a un precio más favorable, y los beneficios se obtienen a través de la diferencia de cambio contenida en la transacción. En tal modo de ataque, podemos ver que cuando hay una transacción de la víctima en el mercado, esta transacción suele ser una transacción en AMM, y el atacante utilizará un valor más alto antes de la transacción de la víctima Tarifas de gas para una transacción inicial. Una vez finalizada esta transacción, utilizarán otra transacción para realizar una operación inversa y obtendrán beneficios a través de la diferencia de tipo de cambio entre las transacciones anteriores y posteriores. Esto es lo que llamamos el primer tipo de Frontrunning.

El segundo tipo es el ataque de supresión más común. En el mercado financiero, el tiempo es un factor muy importante. Muchas transacciones ejecutadas un bloque más tarde y un bloque antes provocarán grandes fluctuaciones en el mercado, especialmente si consideramos que algunas transacciones pueden involucrar precios de liquidación. El objetivo principal de esta clase de ataques es tal transacciones críticas. Por ejemplo, esperamos que la transacción se pueda ejecutar en el siguiente bloque. Si un atacante malintencionado observa esta transacción y luego elimina la solicitud de transacción de un bloque específico con una transacción que propone una tarifa de gas más alta, entonces es atacado. La transacción puede esperar hasta el siguiente o los siguientes bloques antes de ser ejecutado. Debido a la diferencia horaria, es posible que no podamos completar las operaciones de mercado de las transacciones críticas a tiempo, lo que resultará en una agitación del mercado relativamente grave.

El tercer ataque se llama Displayment Attack, que es un ataque de arbitraje de una sola vez. Puede imaginar que cuando hacemos algunas transacciones cíclicas, los precios de mercado pueden ser diferentes. Sin embargo, la oportunidad especulativa potencial que trae la diferencia de tipo de cambio es única. Si puedo suavizar la diferencia de tipo de cambio en el mercado a través de transacciones repetidas, entonces los atacantes posteriores no tendrán forma de especular para obtener ganancias. Entonces esto es dirigido a este tipo de oportunidad de arbitraje de una sola vez. Suponemos que Tv es una transacción que obtiene ganancias a través de transacciones de mercado.Después de que un atacante malintencionado observa Tv, puede realizar exactamente el mismo comportamiento de transacción de mercado, pero la única diferencia es que utilizará una transacción de arbitraje propia. tarifa. Luego, se ejecutará por adelantado en el sistema de cadena de bloques real. Dado que primero ejecuta la oportunidad de arbitraje única, la transacción de TV en sí ya no obtendrá beneficios.

Estos tres son los ataques MEV en los que nos estamos centrando actualmente. Debido a la configuración del mecanismo del sistema, la red blockchain tiene algunos problemas endógenos. Cuando decimos que Frontrunning es muy común, la siguiente pregunta natural es si este asunto es realmente un asunto serio y cuánta pérdida de valor causará MEV.

Tenemos una estadística que en menos de un año, las pérdidas financieras causadas por los ataques MEV en el mercado han superado los 80.000 Ethereum, lo que significa que ha causado bastantes pérdidas económicas, por lo que todos estarán atentos a este tema. , muchas personas también consideran cómo eliminar los ataques MEV. Además de prestar atención a las pérdidas económicas, en realidad también pensamos en el impacto adicional de todo el incidente en la red de la cadena de bloques, porque no solo causó pérdidas económicas, sino que también desperdició una cierta cantidad de espacio de bloque.

Cuando existe este problema, todos deben estar constantemente pensando en cómo solucionarlo. La solución actual es transmitir a través de Private Pool, que solía llamarse Servicio de retransmisión. Las transacciones no solo se propagan a través de una red distribuida que exponen los usuarios, sino que proporcionan un canal de comunicación privado que permite una conexión directa entre usuarios y mineros. A través de un canal de comunicación así, puedes imaginar que la ventaja es que ya no tendremos fugas de información. Dado que creemos que Frontrunning también forma parte de MEV, este tipo de Private Pool se introduce en la red con la esperanza de minimizar la aparición de Frontrunning.

En la actualidad, Frontrunning Attack es causado por la fuga de información en el sistema blockchain. También sabemos que algunas personas han propuesto algunos mecanismos nuevos para evitar esta situación. Entonces, si el nuevo mecanismo puede desempeñar un papel y qué tipo de impacto tendrá en el sistema blockchain, naturalmente se convierten en las preguntas que queremos estudiar.

Cuando introduzcamos Private Channel en blockchain, ¿qué impacto tendrá en todo el ecosistema? En primer lugar, ¿será ampliamente aceptado por los usuarios y validadores de bloques? Porque son los participantes principales en todo nuestro sistema. Luego, la segunda pregunta es si ha logrado nuestro objetivo deseado después de ser aceptado, que es reducir las tarifas de transacción y evitar el Frontrunning. El tercer punto es después de que se introduzca el nuevo mecanismo, ¿qué tipo de impacto tendrá en todos los usuarios de todo el sistema? Estas son las tres preguntas de investigación que nos planteamos tras descubrir posibles soluciones.

Construimos modelos para estudiar y explicar el posible impacto de las diferentes elecciones realizadas por diferentes participantes en el mercado, y finalmente hacemos predicciones.Luego comparamos y analizamos el comportamiento de los usuarios del propio mercado y los resultados de nuestro análisis teórico. Luego mostraremos aquí cómo dividir el problema en tres etapas. Involucramos tres suposiciones diferentes en nuestro modelo de tres etapas. La primera es que pensamos que los participantes son racionales, lo cual es una suposición común que hacemos en muchas investigaciones económicas y financieras. En segundo lugar, pensaremos que algunas transacciones enfrentarán el riesgo de ser atacadas, y habrá algunas transacciones que nunca serán atacadas en el sistema, al mismo tiempo, construiremos un modelo basado en los arbitrajistas o atacantes que existen en este mercado

En todo el sistema, creemos que todas las transacciones tienen dos canales de transacción diferentes, uno es nuestra red común pública distribuida Public Pool y el otro es la red privada Private Pool. Finalmente asumimos que cada bloque tiene suficiente espacio para acomodar transacciones. A continuación, en diferentes pasos de este modelo, cada usuario y cada verificador debe elegir una de las redes para transacciones. En primer lugar, la primera opción es el verificador, la segunda es el usuario y la última es el atacante. Esto está en línea con nuestro modo de funcionamiento normal en el sistema de bloques. Después de que estos tres participantes diferentes hagan sus elecciones, realizamos un cálculo inverso del estado en el que finalmente entrará todo el mercado.

En primer lugar, los mineros tienen dos opciones diferentes: la primera opción es no unirse al sistema Flashbots y la segunda opción es unirse a él. Obviamente, estas dos opciones siempre existen para ellos, si se quedan en el canal público, solo pueden ver las transacciones que existen en el Mempool público. Pero si se unen al Private Pool, pueden ver no solo las transacciones de Mempool, sino también las transacciones en el Private Pool. En la primera etapa del modelo, todos harán una selección, y luego usamos alfa para indicar la proporción de la selección usando el flashbox.

La segunda parte trata sobre la elección del usuario en toda la transacción. ¿Elegirán proponer sus propias transacciones en el Mempool, o elegirán proponer en el Pool Privado? Si proponen transacciones en Mempool, correrán el riesgo de ser atacados. También pueden elegir Private Pool, pero existen ciertos riesgos. La principal fuente de este riesgo es que estas transacciones que se unen al Private Pool pueden no ganar el 100% del derecho a registrar el siguiente bloque, pero podemos seguir proponiendo transacciones más adelante.

La tercera etapa es que el atacante observará las transacciones atacables y llevará a cabo las transacciones de ataque. Por ejemplo, un atacante observa la transacción P y decide atacar esta transacción pública. Cuando un atacante envía su propia transacción, también se enfrenta a dos opciones, ya sea en Public Pool o en Flashbox. Si un atacante envía una transacción en el Public Pool, el atacante puede ofertar por ofertas más altas en varias rondas, y el Gas de su transacción aumentará gradualmente. Este es un modo de ataque común en muchos casos. Si está en el Private Pool, el atacante no sabe si hay otros atacantes compitiendo con él al mismo tiempo. Si en el Public Pool, si alguien más compite con el ataque, los atacantes pueden conocerse entre sí. Pero en el Pool Privado, en primer lugar, el atacante no sabe si hay competencia, y en segundo lugar, no sé cuánto gas ha pagado el competidor, por lo que los atacantes se convierten en una nueva relación competitiva, lo que los causará. para hacer compensaciones. La tarifa de gas que están dispuestos a pagar en realidad será muy diferente. Si finalmente se acepta la transacción del atacante, acabará teniendo un Beneficio C, que es también la pérdida económica ocasionada.

Entonces es hora de equilibrar. El primero se trata de usuarios y atacantes, la principal compensación que encuentran es en realidad el riesgo operativo.

Los usuarios deben sopesar si la información de mi transacción se filtrará o si estoy a salvo, y el atacante no le dará su información de transacción a otro atacante. También enfrentan el mismo riesgo operativo, es decir, los validadores de pool privado no tienen el 100% de derecho para registrar el siguiente bloque, por lo que existe una alta probabilidad de que esta transacción no se incluya en el próximo bloque, incluso si es inútil. para pagar suficientes tarifas de gas.

Los usuarios que no se han unido a Flashbots, solo necesitan ordenar estas transacciones de acuerdo con la tarifa de gas de mayor a menor, pero si se unen a Flashbots, primero deben clasificar las transacciones propuestas por el Private Pool en el bloque y luego verificar el resto. del trato Por ejemplo, la transacción K es más pequeña que la tarifa de gas de sus transacciones anteriores y posteriores, pero la transacción K aún se coloca al frente para su verificación.

Después de establecer el catálogo de modelos hipotéticos, analizaremos gradualmente qué elecciones tomará desde tres perspectivas. Primero realizamos un análisis de comportamiento desde la perspectiva del atacante. Los atacantes, naturalmente, enfrentarán tarifas de gas cada vez más altas después de pasar por una competencia continua. Esta es una conclusión central: encontraremos que el precio del gas que deben enviar en el Pool privado es mucho más alto que el precio del gas que deben enviar en el Pool público. precio. Pero muchos de ellos seguirán eligiendo Private Pool. Hay dos razones principales. La primera razón es que las transacciones de arbitraje que envían en Private Pool no serán vistas por otros atacantes, y no necesitan realizar ofertas, esto es un beneficio. . La segunda ventaja radica en el orden de clasificación de los bloques, si se presenta a través del Private Pool, su prioridad es naturalmente superior a los propuestos por el Public Pool. En este caso, los atacantes naturalmente elegirán Private Pool. Al mismo tiempo, para evitar el impacto de los riesgos operativos, también optarán por comerciar en algunos Public Pools al mismo tiempo.

El siguiente paso es la compensación para los usuarios, que considerarán principalmente dos factores, uno es la tasa de adopción y el otro es la probabilidad de posibles ataques. Si a es relativamente grande, puede imaginarse que el riesgo operativo al que se enfrentan es relativamente pequeño y, naturalmente, estarán más inclinados a utilizar Private Pool. Si el alfa es muy pequeño, puede que no les resulte útil enviarlos en el pasado, por lo que el Public Pool se convertirá en su elección.

También para la parte c, en realidad es un factor muy importante. Descubrimos que si C es lo suficientemente grande, en realidad no tienen otra opción que proponer una transacción en el Pool privado. Si esto sucede, podemos averiguarlo. De hecho, las oportunidades de arbitraje para los atacantes se eliminan por completo.Si todos no usan el Pool público, entonces este asunto ya no existirá. Pero también tenemos que considerar un punto: de hecho, en la operación real, no todas las transacciones que causan MEV tienen un espacio de arbitraje tan alto.

Lo que podemos ver en este momento es, digamos, muchas ofertas que se pueden intercalar y tal vez solo tengan unos pocos dólares a cambio. Después de que el atacante completa el ataque, a veces incluso tiene que distribuir la mayor parte de las ganancias a los mineros, y el incentivo restante puede ser inferior a $1. De hecho, hay muchos casos en los que C es muy pequeño. En este caso, no elegirán Private Channel, porque Private Channel no es una opción óptima para ellos. La razón principal es que, para muchos usuarios, no les importa si sus transacciones son atacadas o no, están dispuestos a correr el riesgo de ser atacados y sienten que correr riesgos es algo peor para ellos. En este caso, sabemos que si la tasa de adopción no es del 100 %, se deben atacar muchas transacciones.

Luego de responder a la segunda pregunta, ¿se ha reducido la tarifa de prioridad? Nuestra conclusión final es que incluso después de que introduzcamos Private Pool, la tarifa de prioridad no se reducirá. Hay dos factores principales aquí: la primera parte, de hecho, como puede imaginar, los verificadores elegirán usar Private Pool solo cuando obtengan tarifas más altas, lo que naturalmente aumenta la tarifa de referencia para ingresar al bloque. Otro factor es que algunas personas pueden ser vulnerables a los ataques, por lo que no están dispuestas a elegir el Pool público. En este momento, prefieren usar el Pool privado para las transacciones. Estas transacciones que no aparecerían en el Pool privado aumentarán aún más la prioridad. tarifa. La conclusión central final es que ha llevado a un aumento en las tarifas de prioridad.

La última pregunta central es si el valor total de los bloques que nos preocupan ha aumentado. Podemos pensar en este factor central porque el canal privado en realidad no puede lograr una tasa de adopción del 100 %, por lo que todavía habrá mucho Frontrunning, que ocupará nuestro propio espacio de bloque. Luego, después de la introducción, dado que estos Running Attacks que generan MEV en realidad no aportan nuevos beneficios de red al sistema, obtienen una parte de las recompensas de los usuarios atacados como sus propios rendimientos especulativos, y no aportarán nada al sistema. Nuevo valor, por lo que desde este punto de vista, incluso después de tener un Private Pool, aún no podemos lograr el estado de asignación óptimo y efectivo de la red. Al mismo tiempo, debido a la existencia de MEV, en todo el sistema, cuanto mayor sea el bienestar general de la red, la opción más beneficiosa para los verificadores no lo es. En este caso, la elección de los mineros también conducirá al hecho de que el bienestar de la red de nuestro sistema final no pueda alcanzar una solución óptima.

A continuación, iremos más allá para discutir si existen algunos métodos potenciales para ayudarnos a resolver tales problemas. El argumento central es que el rendimiento especulativo del atacante y la asignación óptima de recursos de la red son en realidad incompatibles. Los atacantes necesitan la generación de MEV para ayudarlos a aumentar su tasa de retorno. De hecho, un método posible es cambiar la distribución desigual del valor de la red, es decir, proporcionar un incentivo para que los atacantes participen en un método de participación en la red más razonable y efectivo.

Finalmente, me gustaría compartir brevemente con ustedes algunos datos que obtuvimos después del análisis teórico. En primer lugar, observamos la tasa de aceptación de Flashbots. Lo que hacemos principalmente es ver si el bloque de transacciones se refleja intuitivamente en esta parte de los datos. Luego encontramos que la transacción todavía se encuentra en ese estado en este momento, ni todos lo han visto, ni quiere decir que todos puedan verlo.Esta es nuestra primera conclusión. La segunda conclusión que obtuvimos es que la probabilidad de que los usuarios elijan Private Pool en realidad tiene una correlación positiva muy obvia con el hecho de que sean vulnerables a los ataques.

En la tercera parte, obtuvimos una conclusión relacionada con el tiempo. Descubrimos que, en comparación con los atacantes en Mempool, los atacantes en Private Pool no necesitan ofertar ronda tras ronda. Los atacantes que obtienen MEV, tienen que someterse a Las tarifas de los mineros son mucho más altas. En Public Pool, la tasa de pago promedio es de alrededor de 0,3, pero en Flashbox ha aumentado a cerca de 0,8. Descubrimos que la probabilidad de elegir un grupo privado en realidad está positivamente correlacionada con el riesgo de ser atacado. Esta imagen es una distribución de probabilidad tal que puede ver, y luego descubrimos que cuando la probabilidad de ser atacado aumenta en un 1 %, entonces su preferencia por elegir Private Pool aumentará en un 0,6 %.

Nuestra primera y principal conclusión es que su Private Pool no puede eliminar por completo el riesgo de ser atacado, ni puede reducir las tarifas del mercado. En segundo lugar, descubrimos que la introducción de Private Pool aumentará el bienestar de los validadores y reducirá el bienestar de los atacantes. El bienestar general de la red aumentará debido a una asignación de espacio de bloque más efectiva, pero no puede alcanzar el estado óptimo.

Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
  • Recompensa
  • Comentar
  • Compartir
Comentar
0/400
Sin comentarios
  • Anclado
Comercie con criptomonedas en cualquier lugar y en cualquier momento
qrCode
Escanee para descargar la aplicación Gate.io
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)