Reducción de la ejecución frontal en un DEX – THORChain

Cómo THORChain implementa la tecnología para evitar la ejecución inicial en un libro de órdenes público.

THORChain es un protocolo de intercambio descentralizado que permite un único libro de órdenes público que cualquiera puede ver y realizar transacciones.

Los validadores de THORChain reciben órdenes, las validan, las ensamblan en bloques y luego las asignan a la cadena de bloques con un mínimo de 67% de consenso de otros validadores.

Como parte del diseño del protocolo, los validadores de THORChain carecen de permiso, es decir, cualquier persona puede convertirse en un validador apostando Runa suficiente y ejecutando la infraestructura requerida. Además, para evitar el spam de transacciones, se requiere gas para pagar las transacciones y priorizarlas en un bloque. Se crea un mercado de tarifas para que las personas que pagan más por el gas tengan prioridad en sus transacciones.

Frente corriendo

Front-running se refiere a la acción de un comerciante que observa un comercio entrante y luego coloca su comercio delante de él para beneficiarse de él. La ejecución en los intercambios centralizados normalmente no es un problema, ya que solo la entidad de intercambio puede influir en el orden comercial. Si lo hacen o no, se desconoce.

En los intercambios descentralizados donde las órdenes son públicas y hay agentes o mecanismos que pueden influir en el orden de los intercambios, el front-running es más una cuestión pública (ya que los validadores pueden obtener una ventaja injusta para poder front-run).

Los rápidos tiempos de bloqueo de THORChain (menos de un segundo) evitarán en gran medida que cualquiera pueda tener el tiempo de observar una orden y hacer un intercambio frente a ella, pero no se elimina por completo.

Estas son dos situaciones principales que causan una ejecución frontal en THORChain, y esto se explica a continuación.

Mercado de Cuotas

La primera situación que puede permitir a los comerciantes competir de frente es causada por el mercado de tarifas. Un comerciante que desee hacer su pedido frente a otro pagará una tarifa de gas más alta. Luego, los validadores elegirán este intercambio sobre otros y, sin saberlo, causarán una ejecución inicial.

La solución parcial a esto es agregar un límite de max_gas_fee solo a las operaciones, de modo que los operadores que quieran estar protegidos puedan establecer el máximo de gas permitido. Esto eliminará cualquier habilidad para que otro comerciante coloque un comercio por delante de ellos.

Si todas las operaciones se colocan en el límite de max_gas_fee, la única entidad que puede cambiar el orden de las operaciones es el validador que prepara el bloqueo.

Validadores

Los validadores pueden optar por reordenar las transacciones en un bloque antes de prepararlos para el consenso, y pueden hacer el orden de las transacciones a su favor, o en favor de cualquiera que los soborne.

Hay una serie de razones por las que la probabilidad de que un validador de ejecución frontal sea bajo en THORChain:

Tiempos de bloque. Los tiempos de bloqueo en THORChain se llevan a los límites de la latencia para mejorar la experiencia de los intercambios que se construyen en él, así como evitar la posibilidad de que cualquier validador tenga tiempo para observar un cambio y ejecutarlo. Si los tiempos de bloque se empujan a (latencia * 2), donde la latencia es la velocidad promedio que un bloque puede prepararse y comprometerse (500 ms), y el límite de bloque es (tiempos de bloque * 2), donde se omite un validador si pueden. t producir un bloque en este tiempo (2 segundos), luego el validador de ejecución frontal tiene menos de 1 segundo para observar y colocar un comercio a su favor.Block Proposer. El proponente de bloque para un bloque particular se elige en forma de turno rotativo (actualmente). En el caso de que un validador tenga la intención de ejecutarse de frente, tendrían una probabilidad de 1 / n (donde n es el número de validadores en el conjunto) de ser el validador que propone el bloqueo después de que el comerciante haya realizado su pedido. Si hay un gran número de validadores, entonces hay una posibilidad cada vez más baja de que el operador validador ejerza la delantera.Control de comerciante. Si un comerciante sospecha que está siendo liderado por un validador particular, puede elegir transmitir su comercio a un validador diferente.

Esquema de cometer-revelar

Visión general

Un esquema de confirmación de compromiso puede ayudar a resolver el problema de la ejecución frontal. Un comerciante se compromete a un comercio, cifrado con su clave. Dado que el proceso de validación no puede descifrar el comercio, no pueden ejecutarlo en ese momento. Una vez comprometido con el , el comerciante puede elegir revelarlo. El comercio debe ser procesado en el orden en que se realizó. Si bien esto parece que podría resolver el problema, no existe la capacidad de saber si un validador ha recibido un mensaje revelado, y aún tienen la opción de ignorarlo y hacer el pedido comercial a su favor.

La solución a este problema es cifrar todas las operaciones con una clave que un Validador debe conocer: su propia clave. En este caso, el Validador podrá descifrar todas las operaciones y todos los participantes podrán verificar esto. Esta solución se conoce como "oficios ciegos".

Comercio a ciegas con tragamonedas comerciales

Cada bloque contiene un número limitado de espacios comerciales, separados en Operaciones ciegas y Operaciones reveladas, con una tercera sección reservada para transacciones no comerciales. En el bloque N, con Validator X confirmando el bloque, los operadores ciegan sus operaciones con la clave pública de un validador que ejecutará el bloque en el bloque N + n, siendo Validator X + n. El validador actual, que no puede descifrar los contenidos comerciales, los asignará en las ranuras comerciales fijas, asignando a cada una una ranura comercial aleatoria. En el bloque N + n, Validator X + n podrá descifrar todas las operaciones, pero se verá obligado a procesarlas y comprometerlas en el orden asignado aleatoriamente por Validator X. Al mismo tiempo, también reciben y comprometen un número fijo de intercambios ciegos en los espacios de comercio ciego para el siguiente bloque, que ellos mismos no pueden revelar.

Como el Validator X + n no puede reorganizar las operaciones, en su lugar solo puede descifrarlas y procesarlas en orden, por lo que están limitadas significativamente en la capacidad de ejecución frontal.

Si hubieran comprometido su propio pedido en el bloque N, entonces todo lo que pueden hacer es fingir que no pueden descifrar sus propias operaciones y no procesarlas. Sin embargo, si una transacción no se descifra y se confirma en el bloque N + n, entonces esa transacción se invalida para siempre.

El validador X puede intentar conspirar con el validador X + n por delante, pero habrá muy poco tiempo para comunicar las operaciones recibidas y tratar de hacer arreglos con anticipación, y solo puede funcionar si los validadores de colusión son X y X + n. Además, la clave pública que se utiliza para cifrar es la misma clave que se usa para replantear, por lo que la relación entre los validadores en colusión debe ser absoluta y de alta confianza. Una colusión semi-confiable entre dos actores infames resultará en que ambos sean capaces de robarse la estaca mutua, una ganancia económica mucho mayor que la de la primera fila.

Incluso si las claves privadas no se comparten, este problema se puede minimizar mezclando los Validadores y su secuencia de round-robin regularmente.

Este enfoque causa retrasos en el procesamiento de las operaciones por n bloques, y también reduce la cantidad de operaciones que se pueden procesar en un bloque, sin embargo, la ventaja es que la ejecución frontal de los validadores se elimina completamente.

Conclusión

Se considera que un problema en los intercambios descentralizados es un problema, ya que existen mecanismos para que los agentes en el ecosistema influyan en el orden de los intercambios. THORChain implementa un límite de max_gas_fee para las operaciones, además de tener un orden determinista de proponentes de bloque y tiempos de bloqueo rápidos para evitar que se produzca la ejecución inicial. Si un comerciante sospecha que se está ejecutando, puede optar por transmitir sus operaciones a diferentes validadores.

Un esquema de confirmación de compromiso que involucre intercambios cegados y espacios comerciales también puede resolver el problema inicial, pero requerirá más investigación.

Por último, y para no ser subestimado, si un comerciante tiene pruebas verificables de una ejecución anticipada a gran escala, es probable que lo emita en canales fuera de la banda y en las redes sociales. Si el validador ofensor tiene algún voto delegado, puede perder la delegación y abandonar el conjunto de validador. Esta es otra razón para crear un conjunto de validador anti-frágil y sin permisos con alta rotación.

Únete a la Distribución

Para obtener más información o para participar en la distribución, diríjase a https://thorchain.org/token.

Asegúrese de revisar nuestros canales oficiales de la comunidad para las actualizaciones:

Recursos:

PAPEL BLANQUEADO DE THOR CHASEGARDEX