Resumen Técnico: Ordenación por Unanimidad

1. Planteamiento del Problema

Las aplicaciones de blockchain suelen poseer preferencias específicas respecto al orden de ejecución de las transacciones para funcionar correctamente. Los ejemplos incluyen creadores de mercado automatizados (AMMs) que requieren que las actualizaciones de precios de los oráculos precedan a los swaps, bolsas de órdenes que necesitan que las cancelaciones se ejecuten antes que las órdenes de mercado, y subastas on-chain que requieren que las ofertas se procesen de mayor a menor. Actualmente, la ordenación de transacciones está determinada por la blockchain subyacente (por ejemplo, mediante los proponentes de bloques o las tarifas de prioridad), lo que puede no alinearse con estos requisitos específicos de las aplicaciones.

Las soluciones existentes para imponer el orden suelen sacrificar la composibilidad —la capacidad de las aplicaciones para interactuar libremente en un registro compartido—. Por ejemplo, los PropAMMs (AMMs dependientes de oráculos) son factibles en Solana debido a sus reglas de ordenación específicas, pero difíciles de implementar en otros lugares; las bolsas como Hyperliquid han creado cadenas aisladas para asegurar su lógica de ordenación; y los rollups logran el control de la ordenación solo aislando las transacciones de la capa base. Este documento aborda el desafío de otorgar derechos de secuenciación a las aplicaciones sin fragmentar la blockchain ni sacrificar la composibilidad.

2. Metodología: Anulación por Unanimidad (Unanimity Override)

El documento propone una regla de ordenación a nivel de protocolo llamada anulación por unanimidad. La intuición central es que si todas las aplicaciones involucradas en un par de transacciones están de acuerdo en su orden relativo, el protocolo debe respetar dicho acuerdo. Si las aplicaciones discrepan o si las preferencias resultantes forman un ciclo, un mecanismo de respaldo resuelve el conflicto.

El Mecanismo

El algoritmo opera en dos pasos principales:

1. Relación de Unanimidad ($\succ_u$): Se construye una relación dirigida donde una transacción $x_i \succ_u x_j$ si y solo si cada aplicación que interactúa con ambas, $x_i$ y $x_j$, clasifica a $x_i$ por encima de $x_j$, y al menos una aplicación prefiere estrictamente a $x_i$ sobre $x_j$.

   • Esta relación es generalmente incompleta (algunos pares no están clasificados) y no transitiva (pueden formarse ciclos).
   • Los ciclos surgen específicamente cuando las transacciones interactúan con múltiples aplicaciones "con opinión" (aplicaciones que han expresado preferencias estrictas).

2. Ruptura de Ciclos (Respaldo): Para recuperar un orden de ejecución total, el protocolo debe romper los ciclos. El documento introduce una regla de democión:

   • Componentes Cíclicos: El algoritmo identifica componentes fuertmente conexos máximos (ciclos) en el grafo de unanimidad.
   • Democión: Dentro de un componente cíclico, la regla selecciona un conjunto de transacciones para ser "demovidas". Crucialmente, solo las transacciones de opinión múltiple (aquellas que interactúan con $\ge 2$ aplicaciones con opinión) son elegibles para la democión.
   • Lógica de Selección: El respaldo demueve iterativamente la transacción de opinión múltiple con el valor de "orden por defecto" más bajo (por ejemplo, la tarifa de prioridad más baja) hasta que el componente sea acíclico.
   • Relación Reparada ($\tilde{\succ}_u$): Las transacciones demovidas se eliminan de las comparaciones de unanimidad dentro del ciclo y se colocan por debajo de todas las transacciones no demovidas en ese componente. Su orden relativo está determinado por el orden por defecto.
   • Finalización: El orden parcial acíclico resultante se extiende a un orden de ejecución total ($\succ_e$) utilizando un ordenamiento topológico de Kahn inverso, usando el orden por defecto para resolver empates dentro de las capas.

3. Modelo de Amenaza

El análisis asume una forma fuerte de resistencia a la censura (las transacciones no pueden ser retenidas). El atacante se modela como un jugador que puede:

• Desplegar nuevas aplicaciones con preferencias arbitrarias.
• Inyectar transacciones en el bloque con atributos específicos (por ejemplo, tarifa, aplicación objetivo).
• Controlar el orden por defecto ($U_d$) en el peor de los casos (por ejemplo, actuando como el proponente del bloque).
• El atacante no puede modificar las transacciones honestas ni cambiar las preferencias de las aplicaciones honestas existentes.

4. Resultados Clave y Garantías

El documento deriva dos garantías primarias que se mantienen frente a cualquier estrategia de atacante factible, incluyendo aquellos que controlan el orden por defecto:

Garantía 1: La Garantía de Opinión Única

Si una transacción $x$ interactúa con exactamente una aplicación con opinión (una transacción de opinión única), y dicha aplicación prefiere estrictamente $x$ sobre otra transacción $y$ (que puede interactuar con otras aplicaciones), entonces $x$ se ejecutará antes que $y$.

• Razonamiento: Dado que $x$ es de opinión única, ninguna otra aplicación puede expresar una preferencia sobre el par $(x, y)$. Por lo tanto, la clasificación de unanimidad coincide con la preferencia de esa aplicación específica. Debido a que la regla de respaldo nunca demueve transacciones de opinión única, esta preferencia se preserva en el orden de ejecución final.
• Significancia: Esto extiende las garantías de los rollups aislados a la capa base. Las aplicaciones pueden asegurar sus transacciones críticas (como actualizaciones de oráculos o cancelaciones) asegurando que interactúen únicamente con esa aplicación específica, incluso si otras partes de la transacción tocan contratos sin opinión.

Garantía 2: La Garantía de la Región Protegida (Gated Region)

Existe un conjunto de transacciones, $X^*$, denominado la región protegida, que está resguardado contra la reordenación. Una transacción pertenece a $X^*$ si:

1. Ninguna transacción fuera de $X^*$ (ya sea preexistente o inyectable por el atacante) puede ser clasificada unánimemente por encima de ella.
2. El subgrafo de relaciones de unanimidad restringido a $X^*$ es acíclico.

• Resultado: Ningún miembro de $X^*$ es jamás demovido. En consecuencia, si una transacción en $X^*$ está unánimemente clasificada por encima de otra, se ejecuta primero, independientemente de la capacidad del atacante para inyectar transacciones o controlar el orden por defecto.
• Aplicación: Esto protege transacciones como las actualizaciones de oráculos de direcciones designadas o las cancelaciones que son clasificadas más alto por todos los mercados relevantes, siempre que la "puerta" (el conjunto de transacciones que podrían superar su rango) no pueda ser vulnerada por el atacante.

Vulnerabilidad: Transacciones de Opinión Múltiple

El documento identifica que las transacciones de opinión múltiple (que interactúan con $\ge 2$ aplicaciones con opinión) son las únicas vulnerables a ataques de reordenación. Un atacante puede construir un ciclo que involucre a una transacción de opinión múltiple objetivo e inyectar transacciones para forzar al mecanismo de respaldo a demoverla. Sin embargo, el documento señala que si el objetivo es una transacción de opinión única, tal ataque es imposible.

5. Comparación con Referencias

• Frente al Orden por Defecto Controlado por el Atacante: La anulación por unanimidad reduce estrictamente el conjunto de pares de transacciones reversibles en comparación con un sistema donde el atacante tiene control total sobre el orden del bloque.
• Frente al Orden por Tarifa de Prioridad: La comparación es matizada. La anulación por unanimidad protege las transacciones de opinión única y las de la región protegida independientemente de las tarifas. Sin embargo, para las transacciones de opinión múltiple no protegidas, el costo de un ataque (por ejemplo, el front-running) puede ser mayor o menor dependiendo de la topología específica del ciclo y la estructura de tarifas. El documento señala que los ataques de griefing (reordenar transacciones honestas para dañar a un competidor) son posibles bajo la anulación por unanimidad, pero imposibles bajo el orden puro por tarifa de prioridad.

6. Significancia y Alcance

El documento afirma proporcionar un mecanismo que expande el espacio de diseño de aplicaciones en las blockchains sin sacrificar la composibilidad.

• Preservación de Garantías: Permite a las aplicaciones imponer preferencias de ordenación (como actualizaciones de oráculos antes de swaps o cancelaciones antes de trades) sin requerir el aislamiento en cadenas separadas o rollups.
• Alineación de Incentivos: El mecanismo informa de antemano a los emisores qué transacciones son seguras. Por ejemplo, en una subasta on-chain, los postores tienen el incentivo de mantener sus ofertas como transacciones de opinión única para asegurar que no sean demovidas, garantizando así que la subasta funcione según lo previsto.
• Contribución Teórica: El trabajo conecta la ordenación de transacciones con la teoría de la elección social. Reconoce que la relación de unanimidad no es transitiva (una consecuencia del Teorema de la Imposibilidad de Arrow) y propone una regla de agregación de tipo Pareto que sacrifica la "independencia de las alternativas irrelevantes" para lograr un orden de ejecución completo y acíclico.

El documento concluye señalando que la definición de los conjuntos de interacción (qué aplicaciones toca una transacción) es un desafío práctico. Discute el compromiso entre el uso de interacciones declaradas (más fáciles de verificar, pero potencialmente sobreestimando el estatus de opinión múltiple) e interacciones reales (garantías más fuertes, pero que requieren una solución de punto fijo para la consistencia). El análisis actual asume que los conjuntos de interacción son dados.