Cómo Resolver la Vulnerabilidad Frontrunning en Contratos Inteligentes

Incluso si las colas en el supermercado o en los puntos de venta donde paga sus facturas de servicios públicos son historia, algunos de nosotros sabemos lo que se siente cuando alguien se mete en la fila.

Al frente de la cola, eso es. En particular, si es porque su factura tiene un valor mucho mayor en comparación con los demás que hacen cola. Claramente, esto no debería ser un criterio cuando se trata de la prontitud del servicio.

Ahora, este negocio de ser trasladado al frente de la fila también ocurre en los contratos inteligentes de Ethereum. También conocido como el error de ejecución, cuyo nombre se obtuvo de un fenómeno similar del mercado de valores, las transacciones de contratos inteligentes que pagan tarifas de gas más altas tienden a ser más favorecidas que aquellas que no lo hacen.

Desglosando la vulnerabilidad de vanguardia

Desde el principio, esta vulnerabilidad no ocurre debido a una programación defectuosa, sino que hace uso de la forma en que se ordenan las transacciones y se agregan a un bloque del 'mempool'.

Además de los usuarios habituales que buscan ganar dinero rápido, los mineros tienden a ganar con una transacción de este tipo y es por eso que son los que tienen más probabilidades de estar atentos a dichas transacciones antes de que se agreguen a un bloque. De hecho, una vez que lo hacen, envían una transacción propia a cambio de una recompensa financiera injusta, que termina añadiéndose a un bloque en lugar del que se envió primero.

Lo que hay que tener en cuenta aquí es que las transacciones que se han comprometido con un precio de gas más alto tienden a procesarse primero en comparación con otras. Teniendo esta preferencia en mente, el atacante puede cambiar el resultado de eventos como subastas, intercambios u ofertas iniciales de monedas a su favor simplemente pagando tarifas de gas más altas.

Veamos este ejemplo común para entender cómo funciona la vulnerabilidad frontrunning:

En este ejemplo, tenemos tres actores: Naman, Kaavya y Aishwarya. Naman primero implementa el desafío Hashing como un contrato inteligente para que los otros dos lo resuelvan. Quien resuelva este rompecabezas de hashing obtendrá 10 ether como recompensa.

Ahora, Kaavya encuentra primero la solución hash y la envía con 10 Gwei como tarifas de gas, desde su propio contrato inteligente:

Por otro lado, Aishwarya encuentra la respuesta un poco más tarde y pasa la respuesta correcta a su contrato inteligente con 100 Gwei como tarifas de gas.

Debido a que paga tarifas de gasolina más altas, en lugar de que Kaavya reciba la recompensa de 10 Ether, Aishwarya la recibe, como se muestra a continuación:

En pocas palabras, este es el error frontrunning o de pedido de transacciones, ya que procesa las transacciones en función del valor de la tarifa del gas.

En otras palabras, incluso si Kaavya envió su respuesta antes que Aishwarya, no obtiene nada por sus esfuerzos, como se muestra a continuación:

Dado que este "salto en la fila" de Aishwarya no le sentará bien a Kaavya ni a nadie más, se deben considerar algunas medidas preventivas para nuestro código de contrato inteligente.

3 formas de lidiar con la vulnerabilidad de Frontrunning

Ahora, hay arreglos que pueden prevenir tal pérdida. En otras palabras, deberíamos poder bloquear una transacción como la que debería recibir los 10 Ether.

Método 1: Contador de transacciones

El uso de un contador de transacciones es una de las formas más sencillas de disuadir a cualquier otra persona de obtener la recompensa por cualquier otro medio.

Como puede ver en el código agregado a continuación, se agregó un contador de transacciones que bloquea la transacción realizada por la persona que completó primero el desafío de hashing. Dado que solo el primero en hacerlo debe obtener la recompensa, informamos a todos los participantes que agreguen el valor 0 junto con su solución.

Dado que el valor actual de txCounter será cero para la primera solución presentada, se bloquea. En otras palabras, y como en el ejemplo anterior, Kaavya ingresará su solución y el valor cero para recibir su recompensa de 10 Ether. .

Si alguien más hace esto, la solución no será aceptada ya que el contador de transacciones se ha incrementado a un valor mayor que uno. En ese momento, la recompensa completa de 10 Ether, que debería ir a Kaavya, se transferirá correctamente a ella.

Método 2: Establecer límites de gas

Ahora, con este método, la atención se centra en establecer un límite de gas para todas las transacciones. Ambos, un límite inferior y uno superior, si es necesario.

Como recordará, las transacciones se ordenan en función de la cantidad de tarifas de gas que se han pagado por dicha transacción. Si bien es posible que esto no elimine por completo ese pedido, ciertamente lo reduce en gran medida.

Si observa el código a continuación, todas las transacciones que pagan gasolina por un monto de 1 o menos se realizarán, pero aquellas que intenten saltarse la línea pagando más gasolina no lo harán, gracias al modificador gasThrottle. En este caso, 1 Wei o Gwei podría ser el costo estándar de procesar dicha transacción y que es todo lo que se permitirá.

Entonces, si todas las transacciones no varían tanto en gas en virtud de este acelerador, no surgirá el problema de mostrar preferencia por ciertas transacciones. Si bien este enfoque tiene ventajas, la tarifa de gas pagada seguramente cambiará en el futuro.

Lo que es alto hoy será bajo en un par de años, por lo que Naman debe estar atento a esto en todo momento. O bien, Aish podría aprovechar estos valores cambiantes simplemente esperando un momento.

Método 3: El enfoque de envío submarino

Ahora, si bien los dos enfoques anteriores podrían funcionar para situaciones más simples, en realidad nunca abordan la causa raíz de la vulnerabilidad inicial: la divulgación completa de la información de la transacción tanto a los mineros como a otros usuarios malintencionados.

Debería ser obvio que mientras estas dos partes tengan acceso a la información de cada transacción, la posibilidad de jugar con el sistema persiste. Claramente, es necesario un método mediante el cual esta información sensible al tiempo deba ocultarse y que nos lleve al enfoque de envío submarino, implementado como parte de la biblioteca de contratos inteligentes LibSubmarine .

Cuando uno usa este enfoque, ocultan la información de la transacción de tal manera que los mineros o los usuarios regulares realmente no pueden aprovechar. El cifrado juega un papel importante en la protección de esta información que, según el criterio del propietario, puede revelarse una vez que se agrega a un bloque.

Dicho esto, incluso si este enfoque no es perfecto, el nivel de protección que ofrece es mucho mejor en comparación con los otros métodos, debido a su voluntad de abordar la verdadera razón por la que se lleva a cabo la delantera, tanto en el mundo real como en el futuro. en la cadena de bloques.

Otras estrategias para eludir la vulnerabilidad de vanguardia

Por supuesto, las estrategias discutidas en la sección anterior no son las únicas que protegen los contratos inteligentes de la vulnerabilidad 'frontal'.

Con las cadenas laterales, el pedido se realiza fuera de la cadena mientras que la liquidación se realiza en ella. Dado que estos dos pasos se llevan a cabo en diferentes plataformas, esto no solo tiene beneficios para un mayor rendimiento, sino que disuadirá a los mineros o usuarios regulares de obtener la información necesaria para explotar la vulnerabilidad inicial.

Otra estrategia, incluso si es de naturaleza teórica, consiste en aleatorizar el orden de las transacciones para una ronda particular que se haya comprometido en un esquema de confirmación y revelación. Esto se aplica mediante la lógica de contrato inteligente. Los pioneros no llegarán al frente de la fila con este enfoque porque el pedido está determinado por el contrato inteligente antes mencionado.

Finalmente, otro enfoque implica la implementación del Protocolo Inyectivo donde los usuarios resuelven funciones de retraso verificables para ese valor t tan importante que determina quién recibe el pedido. Como resultado, al poder alejarse del sistema de pedidos aleatorios que utilizan la mayoría de las cadenas de bloques, también se reduce la posibilidad de ataques frontrunning.