Análisis de ventajas y desventajas de los proponentes de concurrencia múltiple (MCP)

Autor: Maven11; Traducción: Xiaozou de Golden Finance

Los Proponentes Concurrentes Múltiples (Multiple Concurrent Proposers, en adelante MCP) se refieren a un mecanismo que permite que múltiples proponentes estén activos simultáneamente (es importante no confundirlo con el Protocolo de Múltiples Contextos o la Computación de Múltiples Partes Segura, aunque existe cierta similitud entre ellos). Es una solución innovadora para abordar el problema de la censura. Este artículo explorará por qué es clave permitir que múltiples proponentes, en lugar de uno solo, sean responsables de la propuesta de bloques, incluyendo su funcionamiento y la significación de su implementación.

Aunque el concepto central de MCP es relativamente fácil de entender, actualmente casi no hay adopción práctica de este mecanismo en la blockchain. Sin embargo, en cierto modo, el modelo de operación de los pools de minería de Bitcoin presenta similitudes con los proponentes concurrentes múltiples: cualquier persona que ejecute un nodo completo de Bitcoin puede hacer que las transacciones sean incluidas en la cadena.

Por otro lado, el mecanismo de construcción multiconcurrente de Solana tiene algunas cosas en común con la implementación de un MCP completo, al menos reflejando la idea de múltiples participantes diferentes que participan en la construcción de bloques (pero no en la propuesta de bloques). En Ethereum, alrededor del 95% de los bloques se construyen a través de MEV-Boost. Si bien hay varios constructores activos al mismo tiempo, solo puede haber un ganador por subasta, por lo que la ventaja que Solana logra a través de múltiples constructores simultáneos no se sostiene aquí. De hecho, actualmente no existe una cadena que permita que varios proponentes tengan derecho a proponer bloques en cualquier momento.

La forma más intuitiva de entender MCP es descomponerlo en dos niveles: múltiples proponentes que proporcionan bloques al mismo tiempo, y la fusión final de estos sub-bloques.

Es probable que estos grupos de proponentes sean subconsejos (similares a los mecanismos existentes de Ethereum), ya que no es práctico tener a todos los validadores involucrados. Esto también significa que es importante garantizar que los subcomités individuales no estén monopolizados por un grupo de participación, de lo contrario, pueden surgir problemas de censura y colusión. Además, es importante tener en cuenta que los legendarios stakers de casas a menudo tienen capacidades técnicas limitadas: MCP aumentará significativamente la complejidad del sistema.

Las siguientes son las ventajas clave del MCP que merece la pena adoptar:

Razones para soportar múltiples proponentes concurrentes:

--Aumentar la resistencia a la censura (especialmente importante bajo las limitaciones actuales)

--Expandir en el nivel del protocolo base en lugar de depender de soluciones externas

--MEV distribuido (ya no determinado por un único proponente o constructor para agrupar transacciones)

Problemas que expondrá directamente la implementación de MCP:

-- La intensificación de la competencia en el orden de las transacciones (¿podría llevar a la aparición del fenómeno PGA?)

--Desafíos simulados causados por transacciones inválidas

--Mejoras en los requisitos de hardware

--Problemas de disponibilidad de datos de transacciones no válidas

--se necesita introducir herramientas de finalización

Analicemos estas características una por una, comenzando por las ventajas, y luego evaluemos si los problemas potenciales representarían un obstáculo para la implementación de cadenas de bloques públicas con una carga técnica pesada.

1. Ventajas de MCP

(1) Aumentar la resistencia a la censura

La mayoría de las cadenas de bloques actuales utilizan un mecanismo de finalidad determinista, y su proceso de consenso se basa en un solo líder para determinar el contenido del bloque (con ligeras diferencias). Una vez que se emite el bloque, la mayoría de los validadores llegan a un consenso y lo incorporan a la cadena canónica. Ethereum acelera la producción de bloques a través de un mecanismo de subcomité (pero se necesita más tiempo para que el conjunto completo de validadores llegue a un consenso). En el marco de MCP, varios proponentes construyen cada uno su propio bloque y eventualmente se fusionan, lo que significa que la entrada de bloque pasa de un solo principal (proponente/constructor/repetidor, estos roles idealmente deberían ser descartados por el MCP) a un modelo multicanal. Esto hace que sea mucho más difícil de revisar. Cuando hay varios cuerpos de empaquetado, la resistencia a la censura del sistema mejorará significativamente.

En el corazón del cuello de botella actual (tenga en cuenta que equipos como Flashbots están mejorando el statu quo) está el hecho de que un solo constructor recibe derechos de construcción de bloques de un solo proponente a través de una subasta, y el repetidor (de confianza) como subastador exacerba aún más la centralización. Si bien el protocolo central de Ethereum está descentralizado, el proceso de transacción en cadena existente no lo es. Solana también se enfrenta a la centralización de los relés/constructores de Jito y está tratando de resolverlo con una solución de re-staking (¡el primer re-staking de rendimiento real "AVS"!). ）。 Los usuarios de Bitcoin pueden resolver el problema de forma autónoma (a un costo menor) ejecutando un nodo completo, pero esto se produce a expensas de la finalidad: Bitcoin utiliza la finalidad probabilística y carece de las "herramientas de finalidad" necesarias para implementar MCP, que se basa en la regla de la cadena más larga.

(2) Ampliación en el nivel del protocolo base

A menudo, gran parte del desarrollo se subcontrata a equipos de terceros para corregir los defectos de diseño inherentes de L1 (no limitado a Ethereum) para resolver problemas centrales del protocolo. Implementar MCP significa tratar directamente con problemas que de otro modo se resolverían/causarían con soluciones fuera de la cadena. Esto aumenta los requisitos de hardware (al tiempo que aumenta la resistencia a la censura), lo que puede ser una compensación que valga la pena dependiendo de la necesidad de descentralización por parte de los usuarios del protocolo. Es probable que Solana, en particular, utilice este enfoque para abordar la centralización de Jito. Además, debido a que el esfuerzo de construcción de bloques se distribuye a múltiples partes, la demanda general de ancho de banda de la red aumentará en última instancia.

(3) MEV disperso

El efecto más único de MCP radica en que, al permitir que el MEV de bloques específicos sea compartido por múltiples proponentes activos (en lugar de ser monopolizado por un solo proponente o constructor), se altera el modelo original de "lotería MEV". Los validadores (la mayoría son entidades empresariales) tienden a buscar flujos de ingresos estables, y este mecanismo también puede prevenir eficazmente que una sola parte extraiga MEV a través de la reordenación de transacciones (situación actual). Esta característica tiene un efecto sinérgico con el objetivo de resistencia a la censura.

Nota: Si has leído nuestros artículos anteriores, es posible que estés familiarizado con el término teorema CAP: estas son las tres características básicas que deben cumplirse para el funcionamiento normal de un sistema distribuido.

C： representa la consistencia (consistency), es decir, la experiencia del usuario debe mantenerse uniforme entre todos los usuarios, y cada vez que se utiliza el sistema, debe sentirse como si estuviera interactuando con una única base de datos.

A： representa la disponibilidad (availability), que es lo que comúnmente llamamos vivacidad (liveness), lo que significa que todos los mensajes deben ser procesados por los nodos del sistema y reflejados en los bloques / consultas posteriores, todas las instrucciones deben ser ejecutadas.

P： representa la tolerancia a particiones (partition tolerance, o resistencia a la censura), lo que significa que el sistema debe mantener la consistencia y disponibilidad incluso cuando sufre ataques o se divide la red de nodos.

MCP es una de las mejores maneras de implementar los elementos clave del teorema CAP (especialmente la resistencia a la censura), que a menudo se agrupan de manera simple como problemas de teoría de juegos. Recuerda: debemos confiar en el protocolo mismo, no en la teoría de juegos.

Sin embargo, las ventajas siempre vienen con un costo, la ley de funcionamiento del teorema CAP indica que los grandes logros siempre vienen con defectos correspondientes: es casi imposible satisfacer todas las características a la vez. Por lo tanto, examinemos los problemas que la implementación de MCP podría desencadenar.

2. Problemas que debe resolver MCP

El problema principal es que el MCP genera, hasta cierto punto, una fase de doble competencia dentro del bloque. Primero está la tarifa de empaquetado de transacciones, y luego la tarifa de ordenación. El manejo de la tarifa de ordenación es especialmente complicado, porque en la primera fase, los productores locales solo tienen una vista de bloque local en lugar de una vista global. Esto significa que calcular con precisión la oferta óptima para una ubicación específica en el bloque es una tarea ardua.

! ch8ILlNsaae7gXUMsXRIibmRDzmECCY1A73W5FDF.png

Esto no solo es difícil de operar, sino que lo más crítico es que (bajo el mecanismo de subasta) nos hará regresar a la era de las subastas de Gas prioritarias (PGA). Aunque la resistencia a la censura tiene una mayor garantía, en esencia revive los problemas que MEV-Boost intentó resolver: la mediana de tarifas de Gas altas en bloques competitivos, la fijación de precios excluyente en la fase de empaquetado, entre otros fenómenos.

Además de los problemas de clasificación, incluidas las vistas locales frente a las globales, existen otros desafíos relacionados con las transacciones. Esto se refiere específicamente al problema causado por transacciones no válidas durante la propagación de la vista local-global del bloque. Teniendo en cuenta que es imposible predecir el impacto de los cambios de estado en las transacciones de otros proponentes al comienzo de la fase (antes de que los subbloques se fusionen en bloques coconstruidos por varios proponentes), puede haber casos en los que los proponentes se pasen transacciones no válidas entre sí (el problema se agrava si estas transacciones se cargan en la cadena como contenido de disponibilidad de datos). También es posible que un validador en el conjunto actual de MCP viole un límite de parámetro (por ejemplo, rompiendo el valor máximo de gas). Si bien esto se puede resolver introduciendo un árbitro (o regla incorporada en el protocolo) que pueda filtrar las transacciones de bajo precio con el mismo cambio de estado por tarifa después de la divulgación de la disponibilidad de los datos, esto nos lleva de nuevo al dilema resuelto de la PGA. Sin embargo, no utilizar mecanismos como las subastas para dar a los buscadores/constructores el control sobre las ubicaciones de los bloques conduciría a una avalancha de transacciones de spam y empeoraría la latencia del juego, todo lo cual socavaría la posibilidad de preconfs. Ethereum (después de la actualización de Pectra) y Solana tienen consideraciones adicionales: la propuesta 7702 de Ethereum hace que las transacciones ya no se invaliden debido a nonces, y Solana no tiene nonce de transacción (la cuenta nonce todavía existe). Esto hace que sea mucho más difícil juzgar la validez de una transacción, esencialmente simulando todas las combinaciones para determinar el orden correcto, lo que puede ejercer una gran presión sobre el ancho de banda de la red. Solana puede ser más fácil de manejar con su alta barrera de entrada de hardware, pero Ethereum sin duda necesitará una actualización de hardware. Sin embargo, la posible solución de Ethereum es que el cliente de ejecución (no el constructor + repetidor) calcule realmente el orden durante la fase de fusión de subbloques, lo que reafirma la necesidad de una actualización de hardware.

En términos de disponibilidad de datos (DA), como se mencionó anteriormente, otro problema importante es que estas transacciones no válidas pueden filtrarse en la cadena (esencialmente convirtiéndose en transacciones gratuitas). Esto agrava aún más la carga del cálculo de simulación mencionado en la fase de preconsenso, aunque puede filtrar las transacciones no válidas durante la fase de fusión. Algunas de las implementaciones existentes de FOCIL (dirección de envío en lugar de transacción completa) se pueden reutilizar (a menos que se basen únicamente en la validación de simulación, pero la intervención humana en lugar de las reglas de protocolo puede interferir con el proceso de simulación al invalidar otras transacciones).

Como se mencionó anteriormente, la implementación de MCP probablemente requerirá herramientas finales para abordar los problemas de sincronización, lo que también se sugirió en la sección de simulación de ordenamiento previo al consenso. Esto también provocará problemas de juegos de tiempo en la propuesta de bloques retrasados (fenómenos de este tipo ya son visibles en las subastas de MEV-Boost), cuyos efectos incluyen: los proponentes pueden observar otros bloques antes de construir el suyo, enviando deliberadamente transacciones que invaliden las de otros (lo cual es especialmente ventajoso para los buscadores). Si se establecen reglas demasiado estrictas contra los juegos de tiempo, también se podría llevar a la eliminación de validadores con un rendimiento deficiente (lo que significa más casos de bloques perdidos).

Las posibles soluciones al juego del tiempo se pueden tomar prestadas de las mejoras de cadenas como Monad, que utilizan un mecanismo de ejecución asíncrona (ejecución diferida). Por ejemplo, puede establecer una regla: el efecto completo del conjunto de transacciones de todos los proponentes activos en un solo período de tiempo debe esperar hasta que se construyan todos los conjuntos. Esto limita significativamente el rendimiento, ya que existe una alta probabilidad de que varios proponentes contengan la misma transacción. La ejecución retrasada también significa que incluso si una transacción está "incluida" en un subbloque, es posible que no llegue al bloque de fusión final, lo que resulta en una transacción "incluida pero revertida" (haciéndose eco del problema de doble inclusión mencionado al principio). Tenga en cuenta que esto puede requerir herramientas de finalidad específicas para realizar dichas operaciones (incluida la ejecución, propagación y finalización de bloques).

Aunque nos centramos principalmente en Ethereum, es importante notar que Solana está avanzando activamente en el MCP. Con la llegada de Max Resnick a Anza y la declaración pública de Anatoly apoyando su implementación, esta tendencia se vuelve cada vez más evidente. En un artículo reciente, Anatoly mencionó los siguientes puntos clave de atención:

--¿Qué pasa si los bloques de diferentes validadores llegan en diferentes momentos (esto también podría ser una lucha temporal)?

--Cómo fusionar transacciones (ya se ha discutido anteriormente)

--Cómo distribuir la capacidad de bloque (límite máximo de Gas) entre los validadores para maximizar el ancho de banda

--Problemas de desperdicio de recursos (la misma transacción incluida en múltiples sub-bloques, este problema también se mencionó anteriormente)

Los numerosos problemas de implementar MCP en Solana a menudo reflejan los problemas que enfrenta Ethereum. Sin embargo, Solana se centra más en la optimización del ancho de banda y el rendimiento, lo que significa que, al asegurar la robustez del consenso, la gestión de recursos de bloques y la fusión de bloques son más importantes.

Otro punto clave que mencionamos al principio del artículo es que MCP no solo endurece el protocolo, sino que también se puede usar para extender el protocolo. Incluso puede incorporar la serialización específica de la aplicación (ASS) en la capa de protocolo a través de un mecanismo de clasificación. En el futuro, puede haber un escenario en el que, en lugar de ser el proponente de la transacción XYZ, la propia aplicación actúe como proponente y ordene el conjunto de transacciones según sus propias necesidades (que es en lo que está trabajando el Proyecto Delta) o, por el contrario, la aplicación proporciona al proponente una recopilación de transacciones. Vale la pena señalar que también se está explorando la opción de transferir el impuesto MEV a la parte aplicadora (iniciador de la transacción) y combinarlo con el MCP (que será más fácil de implementar ya que ya no está controlado por un solo proponente).

En una publicación reciente, Max y Anatoly argumentaron que MCP podría lograr diferenciales de oferta y demanda más estrechos mediante la aplicación de una serialización dedicada (concepto de NASDAQ descentralizado). En el entorno actual, como se mencionó anteriormente, solo un líder puede proponer bloques. Esto significa que cuando el precio fluctúa, la parte cotizante en el libro de órdenes intentará revertir ciertas cotizaciones. Bajo el modelo de proponente único de Solana, solo se puede hacer a través de subastas de Jito debido al monopolio del poder del proponente. Idealmente, como muestra Hyperliquid, las solicitudes de contracargos deberían priorizarse para permitir que los creadores de mercado mantengan diferenciales más ajustados. Por lo tanto, se espera que esto se logre a través de ASS como aplicación: tienen el monopolio del poder de subasta bajo el modelo de líder único, y este monopolio se puede eliminar mediante la adopción de MPC. Sin embargo, es probable que esta solución de ASS se limite a escenarios de aislamiento de estado. La esencia de la propuesta es permitir que los desarrolladores de aplicaciones definan acciones prioritarias (por ejemplo, cancelaciones de pedidos) para cuentas específicas y prioricen las transacciones de mayor prioridad (no necesariamente las transacciones con propinas más altas, sino el alma de la liquidez) para cuentas específicas. La idea central es establecer un umbral de tarifa para las operaciones regulares, al tiempo que se permite que ciertas operaciones prioritarias superen el límite.

El problema de las tarifas de empaquetado y las tarifas de ordenación discutido anteriormente parece tener una solución en Solana. Las tarifas de empaquetado se asignan a los validadores de transacciones, mientras que las tarifas de ordenación se pagan al protocolo (que se destruyen). Al combinar múltiples subbloques, solo es necesario ordenar y ejecutar el conjunto de transacciones combinadas según la tarifa de ordenación preestablecida.

El mecanismo anterior se coordina estrechamente con el mecanismo de propagación de bloques de Solana, Turbine. Los líderes (MCP) utilizan fragmentos de datos (shreds) y los envían a los nodos de retransmisión en la estructura arbórea de Turbine; estos nodos de retransmisión deben contener fragmentos de todos los líderes. Los nodos de retransmisión envían información de confirmación de fragmentos a un líder de consenso único, que debe recopilar suficientes fragmentos de mensajes antes de transmitir y alcanzar consenso.

Con el lanzamiento de Alpenglow, la implementación puede ajustarse para tener en cuenta la eliminación de la arquitectura de nodo de retransmisión de una sola capa y el mecanismo de votación en la cadena (ahora completamente en la cadena). Se espera que estos cambios reduzcan los costos operativos de los validadores, aumentando así el número de validadores y atrayendo a actores menos poderosos técnicamente. Si bien esto es beneficioso para la descentralización, puede afectar el rendimiento de la cadena. Vale la pena explorar cómo responderán a los fallos del validador después de que Solana implemente MCP.

**3、**Prácticas de MCP en otros ecosistemas

El ecosistema Cosmos también está avanzando en la implementación de MCP, y la conocida organización Informal Systems acaba de publicar la especificación multi-proponente bajo el modelo de consenso BFT. Emplean un protocolo de transmisión seguro que requiere que el subbloque de cada validador sea confirmado por otros validadores a través de un mecanismo de escalado de votación. Los bloques de construcción de bloques de Tendermint/CometBFT luego alcanzan un consenso sobre estos conjuntos de subbloques, lo que significa que un validador en particular producirá una gran cantidad de subbloques.

Sei está desarrollando el MCP a través del proyecto Sei Giga (con la intención de convertirse en el primer proyecto implementado), parte de su diseño se inspira en el artículo Autobahn (se recomienda encarecidamente su lectura). La idea central es desacoplar la disponibilidad de datos de la ordenación, acelerando la disponibilidad de datos a través de múltiples canales paralelos, y luego ordenándolos en la cadena global. Esto es ligeramente diferente de la concepción del MCP de Ethereum: los validadores no sincronizan la producción de bloques en intervalos fijos, sino que producen bloques continuamente y luego se combinan en una vista global.

Patrick O'Grady de Commonware también está explorando soluciones relacionadas.

Por último, el proyecto Delta ha diseñado una capa subyacente que cuenta con la funcionalidad de un tablón de anuncios resistente a la censura, mientras que cada aplicación ejecuta su propio ordenamiento concurrente, y los bloques generados se liquidan finalmente en la capa de estado global.