Escrito por Pröfesor Utonio, miembro de DeFi LATAM.
Conocimientos previos a tener en cuenta:
A grandes rasgos, hay dos grandes escuelas de pensamiento acerca de cómo se deberían abordar los problemas que acarrea la extracción de MEV en redes distribuidas:
- MEVA (Subastas de MEV): Aceptar que el MEV siempre se encontrará en blockchain e implementar un sistema de subastas de forma democrática para que la extracción no se vea centralizada en unos pocos actores.
- Mitigación del MEV: implementar mecanismos para minimizar la extracción de MEV ya que causan una amenaza existencial para los usuarios de la red. Sobre esta vereda, suelen argumentar que MEVA le facilita el trabajo a los ladrones.
En este blog exploramos el mecanismo desarrollado por Chainlink e implementado a futuro por Arbitrum para lidiar con el problema del ‘fair-ordering’ en redes distribuidas, y los posibles trade-offs que afronta.
Secuenciador en Arbitrum:
Básicamente, el secuenciador es el actor que toma las txs que envían los usuarios en L2, las ordena y luego envía el conjunto de esas txs agrupadas al contrato en L1.
A diferencia de L1, el orden de las transacciones en Arbitrum está determinado por un contrato en L1 llamado Inbox. El secuenciador es un actor al que se le otorga el poder de reordenar las últimas transacciones en el Inbox.
En la etapa inicial de Arbitrum, el secuenciador se encuentra controlado por Offchain Labs, la compañía detrás de Arbitrum, esto significa que la empresa cuenta con el poder de manipular el orden de las transacciones en los bloques de L2. El secuenciador decide unilateralmente cómo se ordenan las txs, y ya que este poder se encuentra centralizado en una sola entidad, podría verse beneficiado enormemente a costa de los usuarios. Al comienzo, y ya que el secuenciador corre por parte de Offchain Labs, el mecanismo de slashing por mal comportamiento no se encuentra activado.
Al principio, los usuarios estarán confiando en que el secuenciador centralizado no actúe de forma maliciosa, e.g. front-runeando o censurando las txs que procesa.
En las L2, las transacciones no se dirigen hacia a la mempool pública, sino que se concentran en el contrato del rollup en cuestión. En definitiva, lo que sucede es que se transfiere el poder de la extracción de MEV desde los miners / validators en L1 hacia el secuenciador en L2.
‘Fair Ordering’ en blockchain
Dos definiciones opuestas demarcan el orden de las transacciones en un sistema P2P:
- Send-order-fairness. En un mundo utópico, el orden de las transacciones en un bloque se darían por el orden específico en el que los usuarios envían sus txs. Por ejemplo, si un usuario envió una tx1 antes que otro usuario haya enviado una tx2, la tx1 siempre debería procesarse antes que la tx2.
Lo ideal sería que las transacciones se asienten en la red en el mismo orden en que fueron creadas y enviadas a los nodos. Pero dado que en una blockchain el sistema se encuentra distribuido geográficamente, no se puede capturar tal orden.
En la práctica, este escenario es difícilmente alcanzable. Los nodos que conforman la red pueden recibir las transacciones de los usuarios en tiempos diferentes, debido a la ubicación geográfica de ambos (usuarios + nodos) y su respectiva latencia. Por lo tanto, cuentan con diferentes visiones del estado de la blockchain en un momento específico. Cada nodo puede recibir transacciones en momentos ligeramente diferentes, derivando en un orden distinto.
- Receive-order-fairness. Lo que finalmente termina por suceder es que el orden de las transacciones se define observando cuándo la mayoría de los nodos recibieron las transacciones individualmente, de forma local. Esta visión corresponde al concepto de FIFO (First-In-First-Out o ‘primero en entrar, primero en salir’)
Cuando suficientes nodos reciben transacciones y logran un consenso sobre el orden de las mismas, éste ordenamiento será el del estado final. Por ejemplo, si suficientes nodos reciben una transacción tx1 antes de otra transacción tx2, entonces tx1 debe ordenarse antes que tx2 en en el estado final.
Fair Sequencing Services, por Chainlink:
El concepto que busca implementar FSS es el de ‘descentralizar’ el ordenamiento de bloques: en lugar de contar con una sola entidad centralizada que mantenga el poder de crear bloques, el secuenciador es reemplazado por un comité de nodos de Chainlink (DON*), los cuales deciden colectivamente cómo se ordenan las txs en los bloques. La red de oráculos en CL recolectan las transacciones y luego llegan a un consenso sobre su orden, en vez de que un solo líder lo dictamine. Hay dos formas en que los nodos recopilan las txs:
- Los usuarios pueden enviar sus txs normalmente para que se asienten en la mempool pública, y los nodos del comité de Chainlink observan la mempool y recopilan los txs desde allí.
- Los usuarios pueden enviar sus txs directamente a los miembros del comité, y luego éstos deciden cómo se ordenan las txs.
*Decentralize Oracle Network
Los usuarios envían las transacciones simultáneamente a múltiples nodos, y el contenido de las transacciones que envían a los nodos de CL se encuentran cifrados, de modo que el contenido de la transacción se revele sólo después de que se haya llegado a un consenso acerca del orden de las transacciones.
Secure causal ordering en FSS:
Ningún nodo puede ver el contenido de la transacción antes de que se llegue a un consenso sobre el orden de la misma. Las transacciones se ordenan y secuencian antes de que alguien pueda observar su contenido. Es válido aclarar que el SCO en realidad no especifica cómo se deben ordenar las txs en sí, solo especifica que una vez ordenadas las txs, se pueden descifrar.
¿Cómo se implementa?
- Las txs se transmiten al comité en forma encriptada bajo una private key que pertenece al comité de nodos, con su correspondiente public key
- El comité ordena las txs cifradas en función de su llegada a la mayoría del DON
- Después que se haya llegado a un consenso sobre el orden, se descifran. Cuando se revela el contenido de la transacción, es demasiado tarde para front-runearlas.
Siempre habrá actores primarios con la potestad de re-odernar transacciones. Lo que se logra con este mecanismo es transferir este poder. De los miners en L1 → secuenciador centralizado en L2 → nodos de Chainlink
La paradoja de Condorcet
La ‘paradoja del voto’ es un resultado de la teoría de la elección social que indica que las preferencias de voto colectivas no cumplen el supuesto de transitividad aunque las preferencias individuales si lo cumplan
El supuesto de transitividad establece: dadas tres alternativas (A, B y C) se cumplirá el supuesto de transitividad si se dan los siguientes resultados:
- A es mejor que B
- B es mejor que C
Entonces, por el supuesto de transitividad, podemos afirmar que A es mejor que C.
Aplicando la paradoja al ordenamiento de las txs, en el siguiente escenario encontramos 3 nodos: A, B y C. Hay 3 usuarios, los cuales envían 3 transacciones - tx1, tx2 y tx3 - a todos los nodos.
- El nodo A recibe transacciones en el orden tx1, tx2, tx3
- El nodo B recibe transacciones en el orden tx2, tx3, tx1
- El nodo C recibe transacciones en el orden tx3, tx1, tx2
Ahora, 2 nodos (A y C) recibieron la tx1 antes que la tx2, 2 nodos (A y B) recibieron la tx2 antes que la tx3 y 2 nodos (B y C) recibieron la tx3 antes que la tx1. Las 3 visiones de los 3 nodos son diferentes, y paradójicamente, todas son correctas. No hay un único camino que satisfaga a todos los usuarios ya que el orden final dependerá del tiempo en que los nodos vieron las txs de los 3 usuarios.
Un protocolo que quiera implementar un mecanismo de ‘fair ordering’ deberá incluir tx1 antes que tx2; tx2 antes de tx3; y tx3 antes que tx1 en el estado final, un escenario visiblemente contradictorio.
La imposibilidad de un orden justo
El argumento principal sobre la imposibilidad de un orden justo en blockchain es que diferentes nodos pueden recibir la misma transacción de un usuario en tiempos diferentes de llegada, lo que deriva en perspectivas diferentes sobre el orden de las transacciones.
En un escenario en donde el threshold del consenso debe llegar a 2⁄3 de los nodos, y la mayoría necesaria de los nodos para llegar a un acuerdo se encuentran en Europa, un actor o entidad con la suficiente motivación económica puede establecerse geográficamente (o bien rentar espacios) lo más cercano posible de los miners / validators, o dicho de otra forma: elegir un punto medio entre la mayoría de los nodos. Lo que en TradFi se conoce como ‘Collocation’, es también factible en blockchain.
Si un usuario envía su tx primero, pero luego este actor/entidad ubicado mucho más cerca de la mayoría de los nodos envía su tx después que el usuario, su transacción muy probablemente sea procesada por encima de la nuestra debido a la latencia, y las transacciones que envíe siempre se verán propagadas primero por encima del retail user, siéndole a éste imposible competir.
Los usuarios más alejados geográficamente de la mayoría de los nodos contarán con una desventaja sustancial frente a los demás. Incluso si su transacción se envió primero, no importará.
Ya que las transacciones que contiene un bloque son limitadas (blocksize), los usuarios deben contar con una forma de comunicarle al miner que desean que su tx sea procesada primero; en consecuencia, los miners deben contar con una forma de priorizar unas transacciones por encima de otras. Generalmente, los miners ordenan las txs de forma descendente de acuerdo al fee ofertado por los usuarios.
Actualmente en Ethereum, los usuarios para asegurarse un espacio en el siguiente bloque participan en una especie de ‘subasta’ en la cual ofrecen el mayor gasfee que están dispuestos a pagar al miner para que su transacción sea procesada e incluída por encima de las demás en la red.
Lo que potencialmente puede suceder en la práctica si se implementa un mecanismo de ‘fair ordering’ en donde este sistema de ‘subasta’ es desechado, es que los searchers, al no poder sobornar a los miners / validators para contar con un espacio prioritario en el siguiente bloque, terminen por spamear sus txs a los nodos para aumentar las chances de capturar el MEV de forma probabilística, derivando en un aumento del costo del gas en la red y afectando a los usuarios normales.
Tomemos el ejemplo de redes como Polygon o Solana, en donde si bien no se implementa FSS, las transacciones son muy económicas y el costo marginal de spamear la red es irrisorio. La estrategia por excelencia para intentar extraer MEV en redes con un gasfee bajo, es spamear la chain enviando la misma tx una y otra vez hasta que su tx sea finalmente procesada. Aunque éstas txs duplicadas sean revertidas, igualmente consumen un espacio inútil en el bloque, congestionando la red y creando un bottleneck entre los usuarios normales y los bots que intentan extraer MEV. Una pésima experiencia de usuario
¿Cómo puede, entonces, existir el concepto de ‘order fairness’ en web3 sin perjudicar sistemáticamente a unos usuarios y beneficiar enormemente a otros?
El concepto de ‘order-fairness’ en redes distribuidas geográficamente es subjetivo, no es una cuestión de semántica. No hay una única verdad en la visión de los nodos sobre el estado de la blockchain en un momento específico, ya que todos los nodos cuentan con perspectivas diferentes sobre un mismo estado, y todas son potencialmente correctas.
FSS como solución temporal en L2:
Ciertamente, en un rollup diseñado como el de Arbitrum, puede ser una mejor implementación contar con una red distribuida de nodos como lo propone FSS - aunque al contrario de lo que su nombre indica, lejos esté de ser ‘justo’ - para ordenar las transacciones en L2, en vez de concentrar este poder en un solo actor por parte de la empresa.
Claro está que el mecanismo de FSS lejos se encuentra de ser una solución a largo plazo, sino que más bien puede actuar en lo inmediato parcheando el problema de centralización en un solo secuenciador, mientras se desarrolla una idea para descentralizar el secuenciador de una forma realmente eficaz.
Cierto también es que, al implementar FSS, el único token necesario para ‘descentralizar’ el secuenciador termina siendo LINK, sin necesidad que Arbitrum lance un token propio para incentivar a correr un secuenciador.
Further reading: