¿Cómo lograr una secuencia justa de transacciones con MEV modular?

Autor: Maven11

Compilador: Luffy, Foresight News

En las dos primeras partes de esta serie, nos centramos en los problemas técnicos que surgen al dividir la pila y en las mejoras que deben realizarse en el mundo modular. Hemos cubierto una serie de avances de trabajo para abordar los problemas que surgen naturalmente en las configuraciones entre dominios. Sin embargo, en la parte final de la serie, queremos centrarnos más en la experiencia del usuario. Queríamos ver cómo la modularización, la personalización y la especialización pueden ayudar a crear mejores aplicaciones. El capítulo final de esta serie analizará la creatividad y las posibilidades emocionantes y únicas de la modularidad para que los desarrolladores creen experiencias de usuario de Web2 con verificabilidad de Web3.

La razón detrás de la construcción de modularidad no debería ser solo para atender a la narrativa o simplemente ser modular, sino porque nos permite crear aplicaciones mejores, más eficientes y más personalizables. Al construir sistemas modulares y especializados, surgen una serie de características únicas. Algunos de ellos son obvios, mientras que otros son menos obvios. Por lo tanto, nuestro objetivo es proporcionar una visión general de las capacidades del sistema modular que no conocía, como la escalabilidad.

Creemos que una de las capacidades que la modularidad proporciona a los desarrolladores es la capacidad de crear aplicaciones profesionales altamente personalizables que conducen a una mejor experiencia para los usuarios finales. Ya hemos hablado anteriormente de la posibilidad de establecer reglas o reordenar el orden en el que se ejecutan las operaciones.

Las intercalaciones verificables (en lo sucesivo, VSR) son una de las oportunidades interesantes que ofrece la clasificación controlada, especialmente para los desarrolladores interesados en construir sistemas comerciales "más justos" en términos de ejecución. Obviamente, la relación entre las pérdidas de los proveedores de liquidez y el reequilibrio (LVR) está fuera del alcance de este artículo, por lo que evitaremos tocar demasiado de esto. Tenga en cuenta que la configuración que vamos a explicar es principalmente para el AMM y no para el modelo de libro de órdenes. Además, CLOB (e incluso CEX) también se beneficiarán enormemente al aprovechar las intercalaciones verificables que se ajusten a su configuración específica. En una configuración fuera de la cadena, existe una clara necesidad de algún concepto de conocimiento cero o ejecución optimista respaldada por la seguridad criptoeconómica.

La VSR es particularmente interesante si tenemos en cuenta el hecho de que la mayoría de los inversores minoristas aún no han adoptado (o es poco probable) un enfoque de conservación. La mayoría de los Wallet/DEX tampoco implementan mempools privados, RPC o métodos similares. La mayoría de las transacciones se envían directamente a través de la interfaz (ya sea un agregador o una interfaz DEX). Como resultado, a menos que la aplicación interfiera directamente con sus procesos y la forma en que se procesan los pedidos, el usuario final puede experimentar una ejecución menos que satisfactoria.

Cuando pensamos en dónde se ordena la cadena de suministro de transacciones, el papel de VSR se vuelve obvio. Se encuentra donde los participantes profesionales clasifican (o incluyen) las transacciones, generalmente en función de alguna subasta o tarifa base. Esta secuencia es muy importante porque determina qué operaciones se ejecutan y cuándo. Esencialmente, la persona que tiene la autoridad de clasificación tiene la capacidad de extraer el MEV, generalmente en forma de una tarifa de prioridad (o propina).

Como resultado, podría ser interesante escribir reglas sobre cómo manejar la clasificación para proporcionar una ejecución comercial más justa (en una configuración DEX) al usuario final. Sin embargo, si está construyendo una red de propósito general, debe tratar de evitar seguir tales reglas.

Además, hay algunos MEVs que son importantes, como el Arbitraje, la liquidación, etc. Una idea es crear un canal de "autopista" en la parte superior del bloque, dirigido específicamente a los arbitrajistas y liquidadores en la lista de permitidos, que pagan tarifas más altas y comparten una parte de los ingresos con el protocolo.

En el artículo "Diseño de intercambios DEX confiables con intercalaciones verificables", Matheus V., X. Ferreira y David C. Parkes proponen un modelo en el que el secuenciador de un bloque está sujeto a una serie de restricciones que ejecutan intercalaciones (y esas restricciones son verificables). Sin adherirse a las reglas establecidas, el observador puede generar una prueba de la falla (o dado que las restricciones son matemáticamente verificables, también puede imaginar un circuito ZK con estas restricciones, que usa ZKP como prueba de validez). La idea principal es esencialmente proporcionar una garantía de precio de ejecución al usuario final (trader). Esta garantía asegura que la transacción se ejecute tan bien como la única transacción en el bloque (obviamente, si asumimos una orden de compra/venta/compra/venta basada en el orden de llegada, hay una cierta cantidad de retraso involucrado aquí). La idea básica de las propuestas en el documento es que si funcionan a un mejor precio que el precio disponible en la parte superior del bloque, estas intercalaciones restringirán al constructor (en un escenario de PBS) o al secuenciador de incluir solo transacciones en la misma dirección (por ejemplo, vender/vender). Además, si hay una situación en la que realiza una venta al final de una serie de compras, entonces la venta no se ejecutará (por ejemplo, comprar, comprar, comprar, vender), lo que puede indicar que los buscadores (o constructores/secuenciadores) están utilizando estas compras para empujar el precio a su favor. Básicamente, esto significa que las reglas del protocolo garantizan que los usuarios no serán utilizados para ofrecer un mejor precio (es decir, MEV) a otra persona, o para hacer que el precio baje debido a las tarifas de prioridad. Obviamente, el defecto de la regla aquí (en el caso de vender más que comprar, y viceversa) es que puede obtener un precio de cola larga relativamente bajo.

Para una plataforma general de contratos inteligentes, es casi imposible construir estas reglas como puramente en cadena porque no tiene control sobre la ejecución y el pedido. Al mismo tiempo, está compitiendo con muchos otros, por lo que tratar de obligar a los que están en la parte superior del bloque a pagar una tarifa prioritaria sería innecesariamente costoso. Una de las características de la configuración modular es que permite a los desarrolladores de aplicaciones personalizar cómo debe comportarse su entorno de ejecución. Ya sea que se trate de la intercalación, el uso de una máquina virtual diferente o la realización de cambios personalizados en una máquina virtual existente, como agregar un nuevo código de operación o cambiar el límite de gas, realmente depende del desarrollador, dependiendo de su producto.

En el caso de un resumen que utiliza la disponibilidad de datos, los niveles de consenso y los niveles de liquidación, la configuración posible es la siguiente:

Otra idea posible es la división de transacciones. Imagínese un grupo de transacciones, cómo ejecutar transacciones de órdenes grandes (que causan mucho deslizamiento) y si esta transacción se ejecuta en bloques consecutivos (o al final del bloque si cumple con VSR), ¿es esto justo para el usuario final?

Si al usuario final le preocupa la latencia, es posible que ese usuario no quiera que se divida su pedido. Sin embargo, esto es menos común, y la optimización para la división de operaciones de órdenes más grandes puede resultar en una ejecución más eficiente para la gran mayoría de los usuarios. De cualquier manera, una preocupación es que los buscadores de MEV puedan darse cuenta de estas operaciones secuenciales y tratar de posicionar sus operaciones antes o después de dichos operadores. Sin embargo, debido a las transacciones divididas a pequeña escala en una serie de bloques, el valor total de MEV extraído puede ser mucho menor.

Otra idea interesante que mencionamos anteriormente en el post es utilizar las frecuentes subastas a granel (FBA), defendidas por el legendario Eric Budish y sus colegas, para procesar las transacciones en forma de subasta al por mayor en lugar de en serie. Esto es para ayudar a identificar la demanda superpuesta (CoW) e integrar las oportunidades de arbitraje en el diseño del mecanismo de mercado. Esto también ayuda a "luchar" en partidas diferidas en construcciones continuas de bloques (o batallas de costes prioritarios en bloques en serie). Gracias a Michael Jordan (DBA) por llamar nuestra atención sobre este documento y por su trabajo para mitigar el tueste de latencia. Implementarlo como parte de la selección y recopilación de bifurcaciones de Rollup también es una configuración interesante que los desarrolladores pueden usar, y hemos visto su tracción significativa durante el año pasado, especialmente para Penumbra y CoWSwap. Una posible configuración sería la siguiente:

En esta configuración, no hay una guerra por orden de llegada, por orden de llegada o de tarifas de gas prioritaria, sino más bien un bloque para finalizar la subasta al por mayor en el tiempo entre cada bloque en función de los pedidos acumulados.

En general, donde la mayoría de las transacciones se han trasladado a un mundo "on-chain" sin custodia, Logística de Amazon puede ser una de las formas más eficientes de descubrir precios "reales", dependiendo del tiempo de bloqueo. Aprovechar Logística de Amazon también significa que, dado que todos los pedidos al por mayor son al por mayor y no se revelarán hasta que finalice la subasta (suponiendo que haya algunas configuraciones criptográficas), habrá una reducción significativa en las operaciones anticipadas. Los precios de liquidación son la clave aquí, ya que no tiene sentido reordenar las transacciones.

También es importante tener en cuenta que en 2018, diseños como los que acabamos de cubrir se discutieron en los foros de Ethresear.ch (ver aquí). En la publicación, mencionan dos documentos que proporcionan un mecanismo de subasta masiva en Plasma (un poco como una precuela de los Rollups modernos), donde cada lote acepta órdenes para comprar tokens ERC20 adicionales a un cierto precio límite máximo. Estas órdenes se recopilan a ciertos intervalos y proporcionan un precio de liquidación uniforme para todos los pares comerciales de tokens. La idea general detrás de este modelo es que ayudará a eliminar el fenómeno de front-running que es común en los AMM populares.

Otra cosa importante a tener en cuenta es que en estas configuraciones, el secuenciador puede necesitar algunos incentivos para hacer cumplir (y hacer cumplir) las reglas anteriores. Esto a menudo se pasa por alto, pero gran parte de la infraestructura de la red Blockchain está a cargo de empresas especializadas, cuyo costo es bastante diferente al del participante doméstico promedio. En general, los incentivos son una parte importante de la implementación de la infraestructura de seguridad. También es más probable que los secuenciadores y constructores hagan un mayor esfuerzo cuando los incentivos están alineados con las reglas aplicadas. Esto significa que estas configuraciones también deben tener un mercado activo. Claramente, este tipo de mercado se está volviendo más centralizado, ya que el costo de capital para la especialización puede ser alto. Como resultado, es probable que los Satoshi (y los más ricos) se consoliden y especialicen para capturar la mayor cantidad de valor posible. En este caso, el flujo de pedidos de exclusividad puede ser una flecha en la rodilla para algunos participantes, lo que lleva a un aumento de la centralización. Una tarifa general de Benchmark puede ser suficiente, pero en realidad no empuja a los participantes del ranking hacia la especialización. Como resultado, es posible que desee introducir algunos conceptos que hagan felices a los comerciantes con los resultados a través de incentivos que se adapten a su situación particular.

Esto está claro para la mayoría de la gente, pero aún debe mencionarse cuando se discute el orden de los niveles Rollup. Si puede controlar el orden, será más fácil "extraer" el valor del protocolo. Esto se debe a que usted controla el poder de reordenar las transacciones, que generalmente se basa en tarifas de prioridad (configuraciones de MEV-boost-esque) en la mayoría de las L1. Le proporciona tarifas prioritarias pagadas por participantes complejos que extraen valor en la cadena. Estos participantes suelen estar dispuestos a pagar una cantidad considerable (hasta que ya no sea capaz de aportar valor). Sin embargo, la mayoría de los resúmenes actuales se realizan principalmente por orden de llegada. La mayoría de las extracciones de MEV se llevan a cabo a través de guerras retardadas, lo que ejerce una gran presión sobre la infraestructura de Rollup. Como resultado de lo anterior, es probable que veamos cada vez más rollups que comiencen a implementar una estructura de clasificación con el concepto de tarifas de prioridad (por ejemplo, el mecanismo de mejora del tiempo de Arbitrum).

Otro ejemplo que nos gusta es Uniswap. Actualmente, Uniswap como protocolo "crea" muchas ineficiencias. Estas ineficiencias son explotadas por los participantes que buscan extraer MEV (Arbitraje a expensas de los Proveedores de Liquidez). Al mismo tiempo, estos participantes pagan muchas tarifas para extraer valor, pero nada de ese valor cae en manos del protocolo Uniswap o sus poseedores de tokens. En cambio, una parte significativa de este valor extraído se paga una tarifa prioritaria a los proponentes (validadores) de Ethereum a través de MEV-Boost para obtener el derecho a ser incluido en un bloque que permite capturar valor en algún momento. Como resultado, aunque hay muchas oportunidades de MEV para los flujos de órdenes de Uniswap, ninguna de ellas ha sido capturada por Uniswap.

Si Uniswap es capaz de controlar los pedidos dentro del protocolo (y la capacidad de extraer tarifas prioritarias de los buscadores), puede comercializarse e incluso puede pagar algunas de estas ganancias a los titulares de tokens, proveedores de liquidez u otros. Con los cambios en Uniswap (por ejemplo, UniswapX, etc.) pasando a la ejecución fuera de la cadena (y Ethereum como capa de liquidación), este mecanismo parece cada vez más probable.

Si asumimos un rollup con un mecanismo PBS parcial, el flujo de pedidos y el proceso de comercialización podrían tener el siguiente aspecto:

En consecuencia, la comercialización de los secuenciadores y proponentes de rollup puede seguir la siguiente fórmula:

Emisión (PoS) + Ingresos por tarifas (+prioridad): el costo de DA, publicación estatal, almacenamiento

Una buena manera de ver cuánto valor se está retirando actualmente en Ethereum (especialmente Arbitrage) se puede encontrar en Mevboost.pics, que ofrece una buena visión general de cuánto valor se puede extraer realmente de las ineficiencias.

Además, separar la guerra del gas de la tarifa prioritaria de la estructura fuera de la cadena puede ayudar a contener las interrupciones de la cadena de suministro al aislar la extracción de MEV en el entorno de ejecución. Sin embargo, teniendo en cuenta que si la elección del líder se lleva a cabo en el Rollup, la mayoría del MEV se sorteará en el Rollup, esto deja poco espacio para la estructura subyacente a menos que se incluya la capa DA, las tarifas prioritarias de la capa de liquidación provienen de la consolidación de liquidez u otras economías de escala.

Para aclarar, muchas de estas estructuras pueden funcionar como estructuras puramente fuera de la cadena sin necesidad de puentes de verificación o garantías de seguridad sólidas. Sin embargo, hay algunas compensaciones que deben hacerse allí. Estamos empezando a ver aparecer más de estas cosas, tanto existentes como invisibles. Una cosa que quiero señalar es que la modularidad no significa necesariamente rollups.

La intercalación anterior representa un ejemplo en el que el ajuste fino de la infraestructura puede mejorar drásticamente la aplicación creada sobre ella.