1. El próximo reto para Ethereum: la centralización del constructor

Ethereum se considera a menudo como una de las redes más descentralizadas junto con Bitcoin. Debido a los requisitos de hardware relativamente bajos para operar un nodo Ethereum, casi cualquier persona puede ejecutar un nodo. Sin embargo, hay cierta redundancia, la red cuenta con más de 1 millón de validadores.

(Cuota de mercado de los constructores | Fuente: Relayscan)

Sin embargo, un problema crítico que a menudo se pasa por alto es la centralización del constructor. Los constructores son las entidades que reúnen transacciones y paquetes para crear bloques en la red Ethereum. En los últimos siete días, el 95% de los bloques fueron generados por solo tres constructores.

A pesar de esto, como ha señalado Vitalik Buterin, la centralización del constructor no representa una amenaza grave para la seguridad general de la red Ethereum. Esto se debe a que, incluso si la construcción de bloques está algo centralizada, los validadores (proponentes) que verifican estos bloques permanecen descentralizados. No obstante, la centralización de los constructores puede dar lugar a diversos problemas, como la censura, la búsqueda de rentas y los problemas de vida.

Este artículo explorará el viaje de Flashbots para abordar las externalidades negativas de MEV de Ethereum y examinará cómo SUAVE podría resolver en última instancia los problemas relacionados con MEV, incluida la centralización del constructor.

2. Progreso hasta ahora

2.1 Prueba de trabajo

Antes de la actualización de The Merge, la red Ethereum operaba con PoW consenso, similar a la red Bitcoin, donde los mineros usaban hardware para minar bloques. Durante este período, cuando los buscadores identificaron oportunidades de MEV en el mempool, la única forma de incluir sus transacciones o paquetes en un bloque fue a través de una subasta de gas prioritario (PGA), donde ofertaron tarifas de gas más altas que otros buscadores.

Había problemas fundamentales con este enfoque. Primero, el robo de MEV era un problema. Los mineros podían ver el contenido de las transacciones o paquetes enviados por los buscadores y, en lugar de incluirlos en el bloque por una tarifa prioritaria, podían copiar estas transacciones y robar el MEV ellos mismos. Por lo tanto, los buscadores tenían que confiar en los mineros para obtener ganancias de MEV.

El segundo problema fue la congestión de la red. Cada vez que surgían oportunidades de MEV, los buscadores competían ofreciendo tarifas de mayor prioridad, lo que llevó a una mayor congestión en la red Ethereum. Esto hizo que las tarifas de transacción promedio fueran costosas e impredecibles, lo que afectó negativamente a los usuarios habituales.

(Subasta de Flashbots | Fuente: Flashbots)

Para hacer frente a las externalidades negativas de la MEV en la red PoW Ethereum, Flashbots introdujo la subasta Flashbots, que consiste en mev-geth y mev-relay. Los componentes clave fueron: 1) la lista blanca de mineros, 2) el establecimiento de un mempool privado y 3) la implementación de un sistema de subasta de oferta sellada.

Los usuarios y buscadores podían enviar transacciones o paquetes al mempool privado de Flashbots Auction, que luego se enviaban a los mineros incluidos en la lista blanca utilizando el cliente mev-geth a través de un mev-relay centralizado. Los buscadores expresaron ofertas por sus paquetes, y los mineros usaron mev-geth para incluir los paquetes de ofertas más altas en el bloque.

A diferencia del sistema anterior, los buscadores utilizaban una mempool privada, por lo que sus acciones no afectaban al mercado Ethereum gas y no podían ver las ofertas de otros buscadores, lo que reducía la competencia. En consecuencia, Flashbots Auction redujo efectivamente la congestión en la red Ethereum. Sin embargo, la lista blanca de los mineros seguía siendo necesaria porque aún podían ver el contenido de los paquetes enviados por los buscadores.

(Fuente: Flashbots)

La subasta de Flashbots se adoptó ampliamente, con más del 90% de adopción de mev-geth. Esto redujo significativamente las transacciones fallidas de MEV y redujo las tarifas promedio de gas en la red Ethereum, mitigando efectivamente muchas de las externalidades negativas asociadas con MEV.

2.2 Prueba de participación (PoS)

En septiembre de 2022, la red Ethereum pasó de PoW a PoS con la activación de la actualización The Merge. El proceso de incluir transacciones enviadas por el usuario en bloques se mantuvo prácticamente sin cambios desde PoW. Sin embargo, hubo un problema crítico con la adopción directa de Flashbots Auction: la lista blanca.

En PoW Ethereum, los mineros poseían físicamente su hardware, lo que hacía que el proceso de lista blanca fuera relativamente sencillo. Sin embargo, con el cambio a PoS, una amplia gama de entidades podrían participar en la validación de forma anónima, lo que dificulta enormemente la inclusión en listas blancas.

Para hacer frente a las externalidades negativas de la MEV en PoS Ethereum, Flashbots introdujo un nuevo protocolo llamado MEV-Boost. La hoja de ruta de la red Ethereum incluye la actualización PBS (Proposer-Builder Separation) para descentralizar MEV, y MEV-Boost implementa parte de PBS.

En esta nueva configuración, los constructores de bloques reciben transacciones y paquetes de usuarios y buscadores para crear el bloque completo más valioso, mientras que los proponentes seleccionan el bloque completo de oferta más alta de los constructores de bloques y lo propagan a la red. A diferencia de mev-geth, MEV-Boost actúa como un sidecar para el cliente de consenso, lo que lo hace compatible con cualquier tipo de cliente.

Así es como funciona MEV-Boost:

(MEV-Boost | Fuente: EigenLayer)

1. Los constructores de bloqueo reciben transacciones de buscadores y flujo de órdenes privados, utilizando sus algoritmos de extracción MEV para reordenar las transacciones para obtener la máxima rentabilidad. A continuación, crean un bloque completo y envían una oferta al repetidor.
2. El relé verifica la validez de los bloques recibidos de los constructores y los almacena.
3. El relé envía los encabezados de bloque, junto con las ofertas, al proponente.
4. El proponente selecciona el encabezado de bloque con la oferta más alta de los enviados por el relé y lo firma.
5. La retransmisión revela al proponente el contenido completo del bloque correspondiente a la cabecera firmada.
6. El proponente envía el bloque completo a la red y recoge la oferta adjunta por el constructor de bloques.

(Fuente: mevboost.pics)

Desde la perspectiva de Ethereum validadores, MEV-Boost ofrece una ventaja significativa: no hay necesidad de un proceso de lista blanca. Los validadores simplemente ejecutan MEV-Boost de Flashbots, y los constructores de bloques simplemente extraen el MEV de mayor valor y lo envían como ofertas. Esto significa que los validadores pueden obtener ingresos de MEV sin necesidad de sus propios algoritmos de extracción de MEV. En consecuencia, las ganancias de MEV están descentralizadas en lugar de concentrarse en unas pocas entidades.

(Fuente: mevboost.pics)

A pesar de ser un middleware externo en lugar de un protocolo integrado, MEV-Boost ha sido adoptado con éxito por más del 90% de Ethereum validadores durante un período prolongado. Si bien existe el inconveniente de que los constructores y proponentes deben confiar en el relé, el número de relés ha aumentado a ocho, lo que reduce el dominio del relé de Flashbots y alivia las preocupaciones relacionadas, como la censura.

3. Centralización del constructor

3.1 Por qué los constructores tienden a la centralización

Si bien MEV-Boost ha mitigado muchas de las externalidades negativas asociadas con MEV, el problema de la centralización del constructor, mencionado anteriormente, sigue sin resolverse. Actualmente, alrededor del 90% de los bloques de la red Ethereum son creados por solo tres o cuatro constructores de bloques. Pero, ¿por qué los constructores de bloques tienden a centralizarse? Hay dos razones principales:

Flujo de órdenes exclusivas (EOF)

En primer lugar, el mercado de constructores de bloques es fundamentalmente un mercado en el que el ganador se lo lleva todo. Imagine que usted es un buscador que ha identificado una oportunidad de extracción de MEV y la ha agrupado. ¿A qué constructores enviarás tu paquete? Si bien puede enviarlo a todos los constructores, cuantos más constructores involucre, mayor será el riesgo de robo de MEV, ya que los constructores pueden ver el contenido del paquete. Por lo tanto, su estrategia óptima sería enviar el paquete solo a los primeros constructores con la mayor probabilidad de inclusión de bloques.

(Fuente: Frontier Research, junio de 2023)

El gráfico anterior muestra que los constructores que reciben más paquetes de los buscadores tienen una mayor probabilidad de inclusión en bloques. Este fenómeno acelera el volante de centralización: si un constructor recibe más paquetes de los buscadores, es más probable que construya bloques más rentables. En consecuencia, es más probable que estos bloques sean adoptados por los proponentes en la red Ethereum, lo que incentiva a más buscadores a enviar sus paquetes a ese constructor. El envío de paquetes a constructores menos dominantes podría resultar en retrasos en la inclusión de bloques, dificultando las predicciones de tarifas de gas y potencialmente perdiendo oportunidades de extracción de MEV.

Más allá de esta tendencia natural hacia la centralización, los constructores pueden obtener transacciones o paquetes adicionales a través de EOF. Por ejemplo, un creador específico podría ofrecer garantías de privacidad o una parte del MEV extraído a los usuarios y buscadores que envían transacciones o paquetes exclusivamente a ellos. Este flujo de orden adicional, inaccesible para otros constructores, acelera aún más la centralización del constructor.

De hecho, como se muestra en el gráfico, BloXroute tiene una tasa de inclusión de bloques significativamente mayor en comparación con sus pares. Esto se debe a que BloXroute opera no solo como un generador de bloques, sino también como un servicio de retransmisión, lo que le da una ventaja de latencia en el procesamiento de transacciones. Además, BloXroute obtiene EOF a través de servicios como BackRunMe.

(Distribución MEV | Fuente: BloXroute)

BackRunMe permite a los usuarios enviar transacciones privadas, protegiéndolos de ataques maliciosos como ataques front-running y sándwich. Además, si las ganancias de MEV se generan a partir de la ejecución de las transacciones privadas enviadas a BackRunMe, las ganancias se distribuyen de acuerdo con las proporciones que se muestran en el gráfico. Los usuarios y buscadores pueden disfrutar de varios beneficios utilizando la interfaz de usuario de intercambio de BackRunMe o simplemente cambiando su RPC para enviar transacciones.

Entonces, ¿qué pueden hacer los nuevos constructores de bloques? Desafortunadamente, tienen opciones limitadas aparte de aumentar su participación de mercado con pérdidas u ofrecer servicios para atraer a los usuarios y al EOF de los buscadores. El primer enfoque, conocido como estrategia de subsidio en bloque, implica establecer ofertas más altas que las ganancias de MEV generadas a partir de bloques de construcción para aumentar la tasa de inclusión en bloque. Por ejemplo, el constructor f1b utilizó con éxito esta estrategia para aumentar rápidamente su número de buscadores.

MEV entre dominios

Cuanto más flujo de orden tenga acceso un constructor de bloques, mayor será la probabilidad de generar bloques más rentables. Si algunos constructores de bloques también crean bloques para otras redes, pueden acceder no solo al flujo de órdenes de la red Ethereum, sino también al flujo de órdenes externos. Es probable que esta capacidad conduzca a una mayor centralización en torno a estos constructores.

3.2 ¿Qué debemos hacer?

Hemos explorado por qué el mercado de los constructores tiende a centralizarse. Aunque la centralización de los constructores no representa una amenaza grave para la seguridad debido a la naturaleza descentralizada de los proponentes (validadores) que verifican y propagan bloques, aún puede conducir a problemas como 1) censura, 2) búsqueda de rentas y 3) problemas de vida.

La censura podría abordarse mediante futuras características de Ethereum protocolo como crList, que obligaría de forma nativa a los constructores a incluir todas las transacciones según lo requerido por los proponentes. Sin embargo, abordar la búsqueda de rentas en un mercado monopolístico y resolver los problemas de vida debido al tiempo de inactividad es más difícil.

Por lo tanto, la mejor solución es evitar la centralización del constructor en primer lugar mitigando sus causas principales: EOF y MEV entre dominios. Para abordar estos problemas, Flashbots introdujo el protocolo Single Unifying Auction for Value Expression (SUAVE). (Vale la pena señalar que SUAVE no es la única solución potencial para la centralización del constructor; para una variedad de otras soluciones potenciales, consulte el artículo de Jon Charbonneau 'Decentralizing the Builder Role').

4. Aquí viene SUAVE

4.1 TL; DR

SUAVE se centra en abordar los dos factores principales que contribuyen a la centralización del constructor: EOF y MEV entre dominios. En primer lugar, SUAVE puede aceptar transacciones de todas las redes, lo que permite a los constructores descentralizados extraer inherentemente MEV entre dominios. En segundo lugar, SUAVE optimiza las condiciones para los usuarios manejando de forma privada las preferencias y ofreciendo una parte de las ganancias de MEV.

4.2 Overview

img src="https://s3.ap-northeast-1.amazonaws.com/gimg.gateimg.com/learn/7d845890ce324b0a8964c2bac68c4100198bef79.png" alt="">

(Descripción general de SUAVE | Fuente: Flashbots)

SUAVE es una cadena de bloques separada de la red Ethereum, que ofrece un mempool plug-and-play y un servicio de construcción descentralizado que puede ser utilizado por múltiples redes. Esto permite a otras redes externalizar los complejos procesos de gestión de mempool y construcción de bloques descentralizados a SUAVE. SUAVE consta de tres componentes principales:

Entorno de preferencia universal

Los usuarios y buscadores envían transacciones, paquetes, intenciones y otras expresiones de preferencias al mempool de SUAVE, en lugar del mempool de la red original, junto con sus ofertas. En SUAVE, estas preferencias se tratan como un tipo de transacción nativo. Al agregar preferencias de varios dominios en un solo mempool, aumenta la probabilidad de ejecución óptima. Esta configuración beneficia a los constructores al reducir las barreras de entrada y aumentar las ganancias potenciales.

Mercado de Ejecución Óptima

Los ejecutores (Searchers, Builders, etc.) monitorean el mempool SUAVE y compiten para crear paquetes con las mejores condiciones de ejecución. Un concepto clave introducido aquí es la subasta de flujo de orden (OFA).

En el modelo tradicional MEV-Boost, las ganancias de MEV fluyen en una sola dirección de los usuarios a los buscadores, a los constructores y a los proponentes. Sin embargo, con OFA, los ejecutores compiten por las preferencias de los usuarios, lo que permite a los usuarios recibir también una parte de las ganancias de MEV. Esta estrategia es similar a servicios como BackRunMe, que tienen como objetivo atraer más EOF mediante la redistribución de algunas ganancias de MEV a los usuarios y buscadores. Además, SUAVE garantiza la privacidad de las preferencias en su mempool, protegiéndolas de ataques maliciosos de MEV.

La diferencia es que, si bien tales estrategias pueden conducir a la centralización de constructores específicos en el mercado actual de constructores, SUAVE incorpora OFA en el propio protocolo, dando a todos los constructores descentralizados acceso a estas preferencias. El concepto de OFA, tal y como lo propone Flashbots, ya está implementado en la red Ethereum a través de MEV-Share y posteriormente se incorporará a SUAVE.

Bloquear edificios descentralizados

En los componentes anteriores, la mayoría de las preferencias encuentran su ruta de ejecución óptima. Los constructores de bloques descentralizados luego usan esta información para construir bloques parciales o completos que maximizan las ganancias de MEV, que luego pasan a los validadores de varias redes.

No todas las validadores de otras redes pueden usar SUAVE, de manera similar a como no todas Ethereum validadores usan MEV-Boost. Los validadores que escuchan SUAVE pueden aceptar bloques de SUAVE y agregar bloques rentables a su red. Si no lo saben, los constructores de bloques de SUAVE deben participar en una subasta de gas prioritaria (PGA) para incluir sus bloques. Una vez que se cumplen las preferencias en la cadena de destino, un oráculo notifica a la red SUAVE y la oferta se envía a los ejecutores para su liquidación.

4.3 MEVM

SUAVE es una cadena de bloques que utiliza MEVM como entorno de ejecución. El MEVM se basa en el marco EVM, con precompilaciones agregadas para casos de uso de MEV. Los desarrolladores pueden usar Solidity para crear aplicaciones MEV como contratos inteligentes, lo que permite la construcción descentralizada de infraestructura previamente centralizada relacionada con MEV. Por ejemplo, diferentes métodos de construcción de bloques o subastas de flujo de órdenes se pueden implementar como contratos inteligentes.

Dada la necesidad de datos y cálculos confidenciales, MEVM también ofrece funciones de privacidad. Los nodos de ejecución ejecutan los cálculos sensibles off-chain. Inicialmente, los Flashbots o terceros proporcionarán esto de forma centralizada, pero con el tiempo, se ejecutará en entornos de ejecución de confianza (TEE) como Intel SGX.

5. Resumen y desafíos futuros

En resumen, SUAVE tiene como objetivo recopilar transacciones de todas las redes blockchain y proporcionar bloques con la ejecución más eficiente a esas redes. Si la visión de SUAVE se realiza plenamente, permitirá una verdadera descentralización de MEV, ofreciendo los siguientes beneficios a varios participantes en el ecosistema blockchain:

1. Usuarios: Protegidos de ataques maliciosos de MEV a través de la privacidad y ofrecen la mejor ejecución.
2. Constructores: Pueden competir de manera justa con otros constructores debido a las transacciones de privacidad inherentes de SUAVE y las subastas de flujo de orden (OFA), y tienen acceso a preferencias entre dominios, lo que les permite construir bloques más rentables que cuando operan dentro de un solo dominio.
3. Redes: Puede externalizar fácilmente el proceso de construcción de bloques a SUAVE.

A pesar de su ambiciosa visión, SUAVE aún se encuentra en sus primeras etapas y se enfrenta a varios desafíos antes de que pueda realizarse por completo.

1. Modelo de seguridad: El modelo de seguridad de SUAVE aún no está definido. Dado que es probable que los bloques SUAVE se utilicen en Ethereum y redes L2 basadas en Ethereum, su nivel de seguridad idealmente debería coincidir con el de Ethereum, pero lograr esto es complejo. Hay discusiones sobre si SUAVE debe construirse como un Ethereum L2 o utilizar la seguridad criptoeconómica de EigenLayer.
2. Transacciones atómicas entre dominios: Estas son no garantizadas. Es un desafío procesar transacciones de forma atómica a través de redes con diferentes tiempos de bloque. Una transacción puede tener éxito en una red de tiempo de bloque rápido, pero fallar en una más lenta. Además, dado que no todos los validadores en todas las redes son conscientes de SUAVE, incluidos los bloques a través de una subasta de gas prioritaria (PGA) podría fallar.
3. Diseño de oráculo: Se necesita un diseño de oráculo sofisticado para llevar los resultados de los dominios externos de forma precisa y rápida a SUAVE para su liquidación. Los oráculos deben ser al menos tan seguros como SUAVE, ya que pueden convertirse en vectores de ataque.
4. Experiencia de usuario: Se debe diseñar una experiencia de usuario fácil de usar para SUAVE. Los usuarios deben establecer ofertas para sus preferencias y mantener ETH en la red SUAVE. También es necesaria una interfaz que permita a los usuarios expresar fácilmente varios tipos de preferencias.

La mayor preocupación es si SUAVE puede lograr una tasa de adopción significativa similar a mev-geth o MEV-Boost. Para que SUAVE haga realidad su visión, debe lograr economías de escala. Muchos usuarios de numerosas redes necesitan enviar sus preferencias a SUAVE, y numerosos constructores deben participar para crear un sistema eficiente. Mientras que mev-geth era un cliente y MEV-Boost era un sidecar de middleware que los validadores existentes podían adoptar fácilmente, SUAVE es una red blockchain basada en MEVM. Por lo tanto, queda por ver si este gran sistema puede lograr una adopción significativa en muchas redes.

Disclaimer:

1. Este artículo es una reimpresión de [mirror]. Todos los derechos de autor pertenecen al autor original [00y]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.