Analice el principio y la solución de la transacción anticipada de Ethereum

Como usuario general, puede manejar transacciones anticipadas al establecer un deslizamiento de transacción más bajo y tarifas de gas más altas.

Este artículo tiene como objetivo analizar exhaustivamente el comportamiento de ataque que existe ampliamente en la cadena de bloques de Ethereum: Front-Running (transacciones de escape), a través del estudio de su principio, para encontrar la solución más efectiva y, finalmente, ayudar a los usuarios de DeGate a evitar estos ataques graves y graves. contra sus intereses.

En pocas palabras, Front-Running se refiere a un comportamiento de ataque en el que un robot de vanguardia completa de forma preventiva la transacción de ataque estableciendo una tarifa de Gas más alta mientras una transacción normal está esperando a ser empaquetada, para aprovechar los beneficios del usuario. Mempool es un grupo de transacciones de Ethereum que se han transmitido a la red y esperan ser empaquetadas en bloques. Es la premisa de que se puede implementar Front-Running. Los robots de Front-Running analizan y encuentran objetivos atacables al escanear continuamente las transacciones en Mempool. La figura a continuación es un navegador Mempool, puede suscribirse a las transacciones en Mempool configurando varios elementos de filtro y ver todos los detalles de estas transacciones.

Entre todos los Front-Running, los más típicos y dañinos son los Sandwich Attacks (ataques sándwich) dirigidos a transacciones AMM.Además, también hay ataques front-running dirigidos al arbitraje, transacciones de liquidación y préstamos flash que explotan las vulnerabilidades del sistema para obtener ganancias. Los atacantes son numerosos, están controlados por scripts automatizados y nunca se cansan, por lo que cualquier transacción rentable se verá saturada por ellos, con pocas posibilidades de sobrevivir.

A continuación, nos centramos en el análisis de los ataques tipo sándwich.

Caso de ataque real

Primero, veamos un caso real de ataque tipo sándwich.

Como se puede ver en la figura anterior, se empaquetan tres transacciones en el mismo bloque y una transacción normal se intercala entre dos transacciones de ataque (marcadas por piratas informáticos). El proceso específico es el siguiente:

El usuario primero inicia una transacción normal, compra DG con 237000.705USDC y establece el precio del gas en 40.5Gwei;

Después de que el robot preventivo detectara esta transacción rentable, lanzó inmediatamente un ataque, inició una transacción de compra, fijó el GasPrice en 49,9 Gwei y se adelantó con éxito a la transacción normal del usuario en virtud del mecanismo de competencia de Gas;

Al mismo tiempo, el robot envía otra transacción de venta y también establece GasPrice en 40,5 Gwei. Debido a la secuencia de tiempo, está cerca de completarse la transacción normal del usuario.

Se completa un ataque preventivo perfecto, incluida la tarifa de manejo, el robot gana un total de 16448.012-16310.3-15.2-10.61 = $ 111.9, y este tipo de ataque con dos transacciones de ataque que intercalan una transacción normal se llama vívidamente ataque sándwich.

Uniswap   El volumen de negociación de 24 horas es de aproximadamente 679 millones de dólares estadounidenses, un 3,21 % menos: el valor total actual de los tokens líquidos actuales de la plataforma de negociación descentralizada Uniswap es de aproximadamente 3310 millones de dólares estadounidenses (+2,88 %), y el volumen de negociación de 24 horas es de aproximadamente 679 millones de dólares estadounidenses (-3,21%). Los tres tokens principales con ganancias: LAYER (+115 %), BAO (+93,06 %), DEBASE (+61,30 %); los tres tokens principales con descensos: RBC (-36,37 %), FXS (-18,64 %), MPH (-15,24%) ). [2021/1/24 13:20:23]

Descripción

Para explicar mejor el principio de ataque, agregamos algunos conocimientos previos relevantes.

Sabemos que los principales DEX actuales, como Uniswap, utilizan el mecanismo AMM (Creador de mercado automatizado) y sus precios siguen la fórmula de producto constante. Por ejemplo, si se establece un grupo de liquidez del token A y ETH en Uniswap, la cantidad de A es 1000 y la cantidad de ETH es 100, entonces el producto de las dos cantidades es 100000 y el precio actual de A es 0,1 ETH. Cuando Alice intenta usar 10 ETH para comprar A en el grupo, la cantidad X de A que obtiene se puede deducir mediante la siguiente fórmula (nota: para simplificar el cálculo, la tarifa de manejo no se considera a continuación):

(1000-X)\*(100+10) = 100000, X = 90,9

En esta transacción, el precio de A es 10/90,9 = 0,11, en comparación con el precio original de A, el deslizamiento del precio es:

(0.11-0.1)/0.1\*100% = 10%

Una sola transacción provocó un deslizamiento del 10 % en el precio de la moneda. Se puede ver que cuanto más ilíquido es el grupo, más fácil es generar un deslizamiento cuando se encuentran transacciones grandes. Y si, antes de la transacción normal de gran cantidad del usuario (se espera que la transacción cause un gran deslizamiento), primero compra A y luego vende la A recién comprada después de la transacción normal del usuario, puede obtener una suma de dinero A mucho dinero. Continuando con el ejemplo anterior, supongamos que antes de la transacción de Alice, Bob primero gasta 5 ETH para comprar A, y luego de que se completa la transacción de Alice, Bob vende el A comprado anteriormente, veamos cuál será el resultado.

En primer lugar, está la transacción inicial de Bob:

(1000-X)\*(100+5) = 100000, X = 47,62

Es decir, Bob compra 47,62 A con 5ETH

La siguiente es la transacción normal de Alice. Tenga en cuenta que el número de A en el grupo de liquidez ha cambiado a 952.38, y el número de ETH ha cambiado a 105:

(952,38-X)\*(105+10) = 100000, X = 82,81

Finalmente, Bob vende 47,62 transacciones A. En este momento, el número de A en la liquidez es 869,57 y el número de ETH es 115:

(869,57+47,62)\*(115-Y)=100000, Y=5,97

A través de este ataque frontal, Bob obtuvo una ganancia neta de 5,97-5 = 0,97 ETH, mientras que la pérdida neta de Alice fue de 90,9-82,81 = 8,09 A, ¡y Bob obtuvo su propia ganancia al hacer que Alice sufriera una pérdida por deslizamiento mayor!

Por supuesto, el ataque preventivo real será más complicado y el atacante necesita realizar cálculos más sofisticados para lograr los dos objetivos siguientes:

Deje que el resultado de la transacción del usuario se acerque infinitamente al deslizamiento máximo (max_slippage) establecido por el propio usuario, para lograr el espacio de arbitraje máximo teórico

Logre un equilibrio entre la competitividad de las tarifas y los ingresos, y gane tanto como sea posible en la competencia con otros robots

Usamos un diagrama para describir mejor este proceso:

El usuario está en el punto A y tiene la intención de invertir en_cantidad (usuario) USDT para comprar ETH. Esta transacción normalmente empujará el estado actual a B, y el usuario establece el deslizamiento máximo como B (max_slippage);

El robot de preejecución detectó esta transacción e hizo una transacción de compra de in_amount(robot) USDT antes de la transacción del usuario, empujando el estado actual a A';

A continuación, se ejecuta la transacción del usuario, alcanzando el deslizamiento máximo B (max_slippage) establecido por él;

El robot apresurado vende el ETH comprado en el paso 2, el estado llega al punto C y obtiene out_amount(robot) USDT

El robot preejecutado obtiene ingresos out_amount(robot) - in_amount(robot)-tarifa de manejo

Ahora que hemos visto la letalidad de Front-Running, ¿qué podemos hacer para detener los ataques de Front-Running?

Como usuario general, hay varias formas de lidiar con Front-Running:

Establezca un deslizamiento comercial bajo, como 0.1%, que no dejará espacio para que los bots de vanguardia sean rentables. Desventajas: el deslizamiento es demasiado bajo, por lo que las transacciones grandes son muy fáciles de fallar y las transacciones fallidas aún deben pagar tarifas de manejo altas.

Aumente la tarifa del gas, lo que aumentará el costo de ataque del bot. Desventajas: Esto también aumenta sus propios costos de transacción.

Se puede ver que las soluciones anteriores son inútiles y tienen varias deficiencias. Afortunadamente, muchos equipos se han dado cuenta de los peligros de Front-Running y han propuesto muchas soluciones constructivas. En primer lugar, a través del análisis de todo el proceso de caza, podemos concluir que para lograr el Front-Running se requieren varios elementos:

Publicidad de transacciones: los detalles de las transacciones se pueden obtener en Mempool

Mecanismo de ejecución de transacciones de Ethereum: la transacción se puede completar primero a través de la competencia de gas

Mecanismo de curva de transacción AMM: el mecanismo de producto constante puede causar un gran deslizamiento

Entonces la contramedida es hacer un escándalo por estos elementos.

Publicidad de transacciones

Dado que el robot decide lanzar un ataque analizando las transacciones en Mempool, ¿por qué no encriptar la información de la transacción directamente para que el robot no pueda verla o comprenderla?

Alguien en la comunidad propuso usar zk-SNARKs, una tecnología de prueba de conocimiento cero, para lograr los objetivos anteriores, es decir, usar zk-SNARKs para encriptar y ocultar la información de cada transacción, imposibilitando que los robots comiencen.

Sin embargo, la solución actual no está lo suficientemente madura, necesita consumir tarifas de gas más altas y puede usarse para llevar a cabo ataques de bloqueo, lo que resulta en defectos de la actividad general del sistema.

Mecanismo de ejecución de transacciones de Ethereum

El mecanismo actual de ejecución de transacciones de Ethereum se completa a través de la competencia de Gas, es decir, quien paga la tarifa de Gas más alta, el minero dará prioridad al empaquetado cuya transacción, luego, si evitamos este mecanismo y enviamos la transacción al minero para el empaquetado directo, se elimina la posibilidad de que el robot apresurado ataque en el medio

Por lo tanto, en algunas aplicaciones, como el servicio Taichi de Spark Mining Pool, también se ha aplicado una solución similar a la Capa 0. Los usuarios pueden configurar directamente el nodo Ethereum de Taichi en MetaMask, para que las transacciones se empaqueten directamente sin que aparezcan en Mempool. desventaja es que existe un cierto grado de incertidumbre en la oportunidad de ser empaquetado.

Además, las soluciones con conceptos similares como ArcherSwap construyen un puente entre los comerciantes y los mineros.Los comerciantes pueden pedir a los mineros que empaqueten sus propias transacciones directamente en forma de recompensas, lo que evita la posibilidad de ser Front-Running. Aunque existe la sensación de pagar una tarifa de protección para evitar ser atacado, en realidad reduce el costo del comerciante y tiene la ventaja de no cobrar una tarifa por falla de transacción.

Optimización del algoritmo AMM

Bajo el mecanismo AMM, las transacciones de gran valor generan un deslizamiento de precios excesivo (que puede entenderse como un precio incorrecto temporal), que es el margen de beneficio de Front-Running Si hay un mecanismo AMM que puede reducir el impacto de las transacciones de gran valor transacciones en los precios de transacciones posteriores, puede prevenir eficazmente los ataques Front-Running. Ya en 2018, Vitalik proporcionó una solución en la comunidad técnica de Ethereum: cuando se produce una transacción de intercambio, el precio del conjunto de transacciones no se ajustará al precio real de inmediato, sino que tenderá lentamente al precio real en unos minutos. Esto es como si el grupo de negociación tuviera mucha liquidez de la nada, por lo que llamamos a esta tecnología tecnología Vitrual Balance (saldo virtual). Este nuevo mecanismo puede reducir en gran medida los márgenes de beneficio de los arbitrajistas, defenderse eficazmente de los ataques Front-Running y, al mismo tiempo, aumentar los ingresos de los creadores de mercados de liquidez.

Aumentar la liquidez

Además, hay otra forma de pensar, que es aumentar la liquidez de un rango de precios específico en el grupo de negociación tanto como sea posible. Cuanto mayor sea la liquidez, menor será el deslizamiento. Cuando la liquidez alcanza un cierto nivel, el frente -el robot en ejecución perderá sus ganancias Space, la función centrada en la liquidez de la versión V3 de Uniswap, es un esfuerzo realizado en este sentido.

Tenemos razones para creer que con los esfuerzos incansables de varios equipos, con la evolución continua de varias soluciones y el aterrizaje sucesivo de tecnologías como la nueva generación de AMM y la segunda capa de Ethereum, pronto podremos brindar a los usuarios con un entorno comercial en cadena más justo y seguro.

Escrito por: DeGate

Tags：

AAVE