Parte 1: Cómo llegamos aquíEthereum fue diseñado inicialmente con la idea de que una sola parte manejaría todo el proceso de creación de bloques. Esto implicaba la agregación de transacciones desde el mempool, la creación del encabezado del bloque y la búsqueda del nonce dorado en la prueba de trabajo o simplemente la firma del encabezado del bloque en la prueba de participación. Durante sus primeros años, la construcción de bloques fue sencilla: los nodos mineros extrajeron transacciones de su mempool, las ordenaron según el precio del gas, que significa el trabajo computacional de cada transacción, y se mantuvieron dentro del límite de gas por bloque. Sin embargo, con el auge de las finanzas descentralizadas (DeFi), este enfoque para la construcción de bloques ha experimentado cambios significativos.
La Amenaza Centralizadora de MEVEn DeFi, la secuencia en la que se ordenan las transacciones puede marcar una gran diferencia. Digamos que hay una transacción esperando en el mempool que tiene como objetivo intercambiar 1 ETH por BITCOIN (¡Estoy hablando de HarryPotterObamaSonic10Inu, por supuesto) en UniSwap. La cantidad de BITCOIN que recibirías se basa en la relación actual de ETH a BITCOIN en el pool de UniSwap. Si la transacción de otra persona, intercambiando 2 ETH por BITCOIN, se procesa justo antes que la tuya, terminarás con menos BITCOIN porque la relación de ETH a BITCOIN ha cambiado. Dada la importancia del orden de las transacciones, y los mineros controlan este orden, esto llevó a la aparición de lo que llamamos MEV, o Valor Extraíble Mínimo/Maximal del Minero. MEV representa la ganancia potencial que un minero puede obtener al elegir qué transacciones incluir, excluir o reorganizar.
MEV podría parecer inofensivo al principio. Demonios, incluso podría parecer un impulso para la seguridad de la red, ¿más incentivos para la minería o validación, verdad? Además de las recompensas habituales del bloque y las tarifas de transacción, ahora hay MEV en juego. Pero la realidad está lejos de ser inofensiva. Si se deja sin control, MEV podría convertirse en una fuerza centralizadora potente. Aquí hay una historia para ilustrar esto: Imagina que acabas de enterarte de este juego de MEV y escuchas que los validadores están obteniendo más del 10% de APR debido a esto. ¡Tentador, ¿verdad? ¡Estás dentro! Entonces, envías tus 32 ETH al contrato de participación y pones en marcha un nodo validador. Pero espera un minuto... Solo estás viendo un retorno del 4%. Cuando llega tu turno para proponer un bloque, las transacciones simplemente se alinean por su precio de gas. Sin magia MEV. No estás equipado con los algoritmos y tácticas intrincados para minar ese oro MEV. Sin el conocimiento, estás atrapado con lo predeterminado: ordenar las transacciones por precio de gas.
Aquí es donde entra en juego la atracción centralizadora. Incluso si eres un quant, tu simple computadora, tal vez una raspberry pi, no se compara con sus supercomputadoras que ejecutan jugadas de extracción de MEV de siguiente nivel. El objetivo obvio aquí es apagar tu validador y en su lugar enviar tu ETH a estas configuraciones superpotentes que prometen una parte del pastel de MEV. Avance rápido, y podrías ver que un puñado de estos gigantes básicamente ejecutan la red, un resultado centralizado verdaderamente inquietante. Si esto es a donde se dirigen las cosas, entonces los objetivos fundamentales de Ethereum han fallado. Una red dominada por unos pocos selectos bien podría ser una base de datos centralizada en ese punto.
El nacimiento de FlashbotsPhil Daian, un estudiante de doctorado en Cornell con una especialización en seguridad de contratos inteligentes, fue uno de los primeros identificadores del problema de MEV. En agosto de 2017, publicó un blog titulado "El costo de la descentralización en 0x y EtherDelta". Este blog se inspiró en las vulnerabilidades de primera línea que identificó durante la ICO 0x.
El front-running implica detectar una transacción en la mempool que tiene como objetivo intercambiar Token A por Token B. Un front-runner inicia programáticamente una transacción similar que ofrece un precio de gas más alto. Esta estrategia asegura que la transacción del front-runner se procese antes que la original. Después de que se procesa la transacción inicial, el front-runner puede intercambiar inmediatamente Token B por Token A, terminando con una cantidad mayor de Token A de la que comenzaron. Esta táctica a veces se llama ataque sandwich, ya que la transacción del usuario queda atrapada entre dos transacciones iniciadas por el front-runner. Como resultado, mientras el front-runner obtiene ganancias, el individuo detrás de la transacción original recibe menos de Token B. Si bien los ataques sandwich son comunes, hay diversas estrategias que las personas pueden utilizar para extraer el MEV de manera efectiva.
Visualizando el Ataque del Sándwich: Cómo los Front-runners Obtienen Ganancias a Expensas de Otros
Durante el auge de las ICO, Phil y un equipo desplegaron un bot que ganaba alrededor de un millón de dólares anuales. Después de compartir su metodología en la publicación del blog que mencioné anteriormente, surgieron varios bots similares, creando un panorama competitivo en el que los bots superaban los precios del gas de los demás para lograr la prioridad de transacción. Esto llevó a Phil a implementar nodos a nivel mundial, capturando datos transaccionales en tiempo real. Esta investigación culminó en su famoso Ponencia "Flash Boys 2.0", que profundizó en los desafíos de MEV causados por los intercambios descentralizados.
Aquí hay una divertida historia relacionada que Phil compartió cuando fue invitado en el Bloque de corte. Cuando Hayden Adams, el fundador de UniSwap, compartió su diseño para lo que ahora es el intercambio descentralizado más popular en ethresear.ch. Phil inmediatamente envió sus preocupaciones tanto a Vitalik como a Hayden. Phil creía que el diseño de UniSwap causaría una cantidad significativa de MEV, convirtiéndolo en un objetivo principal para la explotación y poniendo a los usuarios en riesgo de reordenamiento de transacciones y ataques de sandwich. Vitalik respondió sugiriendo que esto podría considerarse simplemente como un mecanismo de tarifa adicional para usar la cadena de bloques. Phil estaba tan enojado con esta respuesta y pensó que entidades financieras poderosas como Goldman Sachs vendrían y se comerían el almuerzo minorista, al igual que el sistema financiero actual. Sin embargo, con el tiempo, Phil ha adoptado la perspectiva de Vitalik (alabado sea el señor Vitalik).
Reconociendo la importancia y los desafíos del espacio MEV, Phil cofundó Flashbots, una empresa centrada en la investigación y las soluciones en el ámbito MEV. Flashbots se dio cuenta de que MEV va a existir y su misión es asegurarse de que la existencia de MEV no conduzca a un sistema en el que ser una mala persona o crear externalidades negativas sea mejor para ti individualmente y sea más rentable que ser un buen actor. Un ejemplo de esto es en TradFi, las estrategias más rentables a menudo implican explotar los bordes del sistema. Además, Flashbots pensó que podría haber una manera de aprovechar la energía de MEV para los usuarios y subsidiar a las personas que aseguran la red y también subsidiar las transacciones en la red para obtener mejores precios para que las personas tengan la ejecución que desean en estos sistemas. Si se diseña correctamente, MEV podría ser parte de lo que hace que las criptomonedas superen a los sistemas tradicionales.
Aprovechando MEV: El papel de las subastas y la separación de propietario-constructorLos flashbots reconocieron que el monopolio de los mineros sobre el orden de las transacciones era un recurso valioso. Su primer paso para democratizar MEV implicó la creación de un sistema de subasta para los derechos de pedido de transacciones. Esto llevó a la creación de MEV GETH, que introdujo por primera vez el concepto de separación proponente-constructor (PBS). Barnabé Monnot, de la Fundación Ethereum, describe PBS como: "Una filosofía de diseño en la que los participantes del protocolo pueden utilizar servicios de terceros durante sus tareas de consenso". Hasta ese momento, los mineros tenían el control total: decidían el orden de las transacciones, hacían el hash y luego añadían el bloque. Pero MEV GETH cambió las cosas. Introdujo actores externos, llamados buscadores, que pagaron por el derecho a que su paquete de transacciones se incluyera en el bloque de mineros.
Con MEV GETH, los mineros tenían un nuevo punto de conexión. Podían recibir paquetes de transacciones optimizados para MEV de los buscadores. Cada paquete también contendría una transacción que proporcionaba a los mineros una comisión, incentivándolos a seleccionar este paquete en particular. Naturalmente, los mineros elegían el paquete que ofrecía la comisión más alta. Cuando los buscadores compiten por oportunidades de MEV en la mempool pública, sus ofertas aumentan naturalmente debido a esta competencia. Esta competencia asegura que los mineros reciban la mayor parte de los beneficios de MEV.
Analicemos esto con un ejemplo: imagina que Alice es una buscadora y detecta una oportunidad de arbitraje entre dos exchanges descentralizados. Podría obtener una ganancia de 0.07 ETH comprando el token X en UniSwap y luego vendiéndolo inmediatamente en SushiSwap por un precio más alto. Por lo tanto, crea un paquete de transacciones optimizado para la oportunidad MEV de 0.07 ETH y está dispuesta a pagarle a un minero 0.05 ETH para priorizar sus transacciones en el siguiente bloque. Bob, otro buscador, identifica la misma oportunidad. Construye un paquete similar, pero ofrece un pago de 0.06 ETH a los mineros por el mismo privilegio. Alice y Bob envían sus paquetes de transacciones optimizados para MEV a los mineros. En el otro extremo, un minero recibe estos paquetes y tiene que decidir cuál incluir en el siguiente bloque. Naturalmente, el minero elige el paquete de Bob debido a la tarifa más alta ofrecida, lo que garantiza que el minero obtenga el máximo beneficio. Es una situación en la que todos ganan.
El minero captura la mayor parte de la oportunidad MEV, recibiendo 0.06 ETH de la oportunidad de 0.07 ETH. Mientras tanto, el buscador se asegura una ganancia neta de 0.01 ETH, que de otro modo no habría podido obtener. La esencia del mecanismo MEV GETH es esta licitación competitiva. Alice y Bob compiten entre sí, ofreciendo incentivos al minero, asegurando así que el minero capture una parte significativa de los beneficios de MEV.
Sin embargo, si simplemente abrieran un endpoint para que cualquiera enviara los paquetes de mineros, los actores maliciosos podrían explotar esta apertura para sobrecargar su sistema, lo que podría lanzar un ataque DOS. Para hacer frente a esta vulnerabilidad, Flashbots introdujo Flashbots Relay. Este relé cumple una función de filtrado crucial: evalúa los paquetes de transacciones entrantes en función de su rentabilidad potencial para los mineros, la validez de las transacciones y la tarifa ofrecida. Solo los paquetes óptimos se envían a los mineros. Este método introduce un nivel de centralización, ya que el proceso depende de Flashbots Relay para filtrar el tráfico no deseado o potencialmente dañino. Curiosamente, ya existía un nivel de PBS entre el operador del pool minero y sus trabajadores. Por lo general, el operador construía el cuerpo del bloque, incluidos los paquetes enviados desde los relés, cifraba el encabezado del bloque una vez y lo enviaba a los trabajadores para que continuaran con el hash y encontraran el nonce dorado.
Visión general de MEV GETH: El viaje desde la búsqueda hasta la inclusión del paquete de transacciones en el bloque del minero
Parte Dos: El Paisaje ActualCuando Ethereum hizo la transición de Prueba de Trabajo (PoW) a Prueba de Participación (PoS), el panorama de validación de transacciones y propuesta de bloques cambió significativamente. Mientras que PoW dependía de mineros y poder computacional (tasa de hash) para validar y agregar nuevos bloques a la cadena de bloques, PoS trasladó esta responsabilidad a validadores que apostarían su ETH para convertirse en proponentes de bloques.
MEV GETH estaba siendo utilizado por casi todos los grupos de minería, pero con Ethereum transitando a PoS, el sistema requería modificaciones. PoS fue diseñado para acomodar apostadores individuales: validadores individuales que operan en dispositivos de recursos bajos como una Raspberry Pi. PoS fue diseñado con el objetivo de asegurar un panorama equilibrado: ya sea que seas un apostador individual o parte de un pool de apuestas sustancial, no habría ninguna ventaja inherente en el proceso de validación para ningún participante. Antes de la transición a PoS, algunos pools de minería dominaban la tasa de hash. Esto permitía una relación de confianza entre estos pools y el Flashbots Relay. Cualquier acción deshonesta, como un pool de minería robando MEV de un buscador, podría poner en peligro esta relación. Imaginemos que un minero recibe un paquete con un ataque de sandwich de un buscador. Si el minero sandwicheara aún más al buscador con sus propias transacciones, podría traer ganancias a corto plazo, pero rompería los lazos con Flashbots, costándoles futuras ganancias de MEV porque perderían acceso al Flashbots Relay.
Presentación de MEV BoostLos validadores individuales, a diferencia de las grandes piscinas de minería, podrían no tener motivaciones a largo plazo para mantener la confianza. En ciertos escenarios, podrían encontrar más rentable explotar el MEV de un creador y posteriormente desaparecer de la red. Esta acción resultaría en que les sean confiscados todos sus fondos, perdiendo los 32 Ether, pero en algunos casos, el beneficio potencial de robar el MEV puede superar esta pérdida. De hecho, esto ocurrió en abril, cuando un validador deshonesto arrebató $20 millones de un bot de sandwich antes de cerrar su validador.Más lecturas sobre este incidente.
En respuesta a este nuevo vector de ataque, Flashbots implementó MEV Boost, un sistema diseñado para un entorno con validadores en solitario.
La mecánica del impulso de MEV:
- Relays: A diferencia del sistema anterior donde solo Flashbots actuaba como el relay, MEV Boost democratiza esto. Ahora, cualquiera puede servir como relay, ampliando la participación y la seguridad. Flashbots también ha hecho público su código relayer.- Constructores: Surge un nuevo rol - el Constructor. Estas entidades recopilan paquetes de transacciones de los buscadores y los combinan en bloques completos.- Sistema de subasta: Los constructores realizan ofertas para incluir sus bloques completos y los envían a los relés. Los relés realizan un paso crucial de verificación para garantizar la validez del bloque.- Interacción del validador: Los relés reenvían la oferta más alta, junto con el encabezado del bloque respectivo, que reciben de los constructores competidores al validador que le toca proponer un bloque a la red de Ethereum.- Compromiso de bloque: El validador designado firma el encabezado del bloque, que es un compromiso. Una vez firmado, quedan vinculados a ese bloque. Si intentan firmar otro bloque, se consideraría un acto malicioso y serían penalizados.- Propuesta final: Con un compromiso establecido, el relé envía los detalles completos del bloque al validador, y formalmente propone a la red.
El proceso de impulso de MEV
Esta configuración introduce problemas de confianza:
-
Confianza en el Relevo del Constructor: Los constructores necesitan confiar en que los relés no robarán su MEV. Considere un escenario en el que un relé, después de recibir un bloque de un constructor, cambia la dirección del constructor en una transacción tipo sándwich por la suya propia. Luego pasan el encabezado manipulado al proponente.- Confianza en el proponente-relé: por otro lado, los proponentes deben confiar en que los encabezados de bloque que firman son válidos. Proponer un bloque inválido resultaría en la pérdida de las recompensas del bloque ya que la red rechazaría dicho bloque.Los diseños de PBS enfrentan un desafío recurrente: si bien las interacciones entre el proponente y los actores de ordenación de transacciones son un hecho, hay una clara necesidad de un mecanismo donde:
-
Los proponentes pueden comprometerse con un bloque de un constructor sin conocer su contenido pero siguen asegurándose de la validez del bloque.- Los constructores pueden enviar de forma segura su bloque al proponente, confiando en que su MEV no será robado.
Aumento de MEV en las suposiciones de confianza
Antes de adentrarnos más en MEV Boost, es esencial entender la forma predeterminada en que Ethereum crea bloques sin el uso de MEV Boost. Esta configuración depende de la colaboración entre un Cliente de Ejecución de validadores y un Cliente de Consenso. Cuando una transacción es recibida por el Cliente de Ejecución, este verifica el formato, la agrega a su mempool, pero no la procesa. Simultáneamente, el Cliente de Consenso maneja el consenso de PoS, seleccionando un validador para crear el siguiente bloque. El Cliente de Ejecución del validador seleccionado luego organiza las transacciones por precio de gas en un nuevo bloque, que luego se envía al Cliente de Consenso y se propaga a la red. Otros validadores atestiguan la precisión del bloque y, una vez verificado, se convierte en el eslabón más reciente de la cadena.
Este proceso cambia si el validador opta por usar MEV Boost. Los validadores que integran MEV Boost lo hacen con su cliente de consenso. Cuando están listos para proponer un bloque, ya no dependen de su Cliente de Ejecución y en su lugar se conectan a una red de relés. Los validadores pueden elegir a qué relés conectarse.
MEV Boost es opcional, pero el 95% de los validadores lo están utilizando. Esencialmente casi todos los validadores, excepto los que son dirigidos por Vitalik, están delegando la construcción de bloques a un tercero. Esta delegación indica que una función fundamental del protocolo Ethereum, la construcción de bloques, ahora se lleva a cabo principalmente fuera del propio sistema Ethereum. Un actor clave en esta configuración es el relé y su papel contrasta en cierta medida con los principios fundamentales de Ethereum. Actualmente, hay alrededor de 9 relés activos, pero solo 6 de ellos tienen más del 9% de participación en los bloques retransmitidos.
Desglose de los principales relés y constructores por cuota de mercado en los últimos 7 días. Fuente: https://www.relayscan.io/
La confianza se convierte en un problema ya que la relación entre los relés y el constructor y entre el relé y el validador no es sin confianza. También hay preocupación por la resistencia a la censura. Los relés, durante sus subastas, tienen la discreción de determinar la validez de los bloques. Esta discreción les permite excluir bloques con transacciones vinculadas a direcciones sancionadas. Un caso concreto es cuando ocurrieron las sanciones de Tornado Cash de la OFAC, algunos relés ejercieron este poder. Los datos recientes muestran que el 38% de los bloques en la semana pasada se adhirieron a las pautas de la OFAC debido a esta censura impuesta por los relés.
Parte Tres: Mirando hacia el futuroEthereum está ideando una estrategia para reincorporar los procesos que actualmente operan fuera de su protocolo central. El objetivo es exigir que los proponentes obtengan bloques de los constructores, permitiendo esencialmente que el protocolo maneje las funciones actuales del relé. El sistema de relé tal como está tiene sus vulnerabilidades. Por ejemplo, un relé podría no validar correctamente un bloque, verificar incorrectamente la oferta del constructor en relación al pago previsto para el proponente, o incluso retrasar o fallar en la entrega de bloques. Además, mantener un relé no es barato. Actualmente, falta un modelo de financiamiento sostenible para ellos. El Ultrasound Relay, el relé más utilizado, dice que sus costos operativos se estiman entre 70k-80k euros anualmente, y eso excluye otros gastos como el mantenimiento del software. Los relés actualmente operan como servicios públicos.
También vale la pena señalar que, dado que MEV Boost es un software externo desarrollado por una empresa (Flashbots), no se ha probado tan rigurosamente como el software dentro del protocolo. Esto fue evidente con el cliente Prism después de la actualización de Shapella: un error de integración con MEV Boost causó problemas con la firma del proponente, lo que provocó la pérdida de espacios y sanciones. El objetivo de integrar este proceso en el protocolo de Ethereum es abordar estos desafíos, asegurando que incluso si un acuerdo entre el proponente y el constructor se desmorona, el proponente sigue siendo reembolsado. Entonces, si un constructor proporciona un bloque defectuoso, el proponente aún recibe la oferta completa, dejando al constructor para asumir las consecuencias. Si bien los detalles de esta integración, denominada ePBS (separación enunciada proponente-constructor), todavía se están investigando y posiblemente a un par de años de realización, ya hay muchas ideas diferentes de cómo podría ser posible verla.
Cómo consagrar la separación entre proponente y constructorPara entender las posibles implementaciones de ePBS, es esencial entender primero algunos componentes básicos del algoritmo PoS de Ethereum. En Ethereum, el tiempo se segmenta en intervalos de 12 segundos llamados slots. 32 de estos slots se unen para formar una época. En cada slot, se selecciona aleatoriamente a un validador para proponer un bloque. Simultáneamente, se designa un comité para atestiguar la validez del bloque que consideran conforme con las reglas de elección de bifurcación PoS de Ethereum, atestiguando idealmente al bloque propuesto más recientemente como la cabeza de la cadena de bloques. Si no se propone un bloque en el slot dado, entonces, 4 segundos después, los validadores que atestiguan atestiguan el bloque anterior.
Ahora, sobre los diseños de ePBS. El modelo más favorecido abarca dos slots. Primero está la fase de licitación, donde los constructores envían sus ofertas a los validadores. Luego, el Slot 1 comienza con el proponente seleccionando una oferta y comprometiéndose con ella publicando un bloque que se compromete con la oferta del constructor. Un grupo de atestiguadores emiten su voto a favor de este bloque, asegurando su lugar en la cadena. En el Slot 2, los constructores ven la oferta que fue comprometida en el bloque comprometido del proponente y las atestaciones sobre ella. Reconociendo el compromiso irreversible del proponente, el constructor cuya oferta fue seleccionada libera su bloque y se asegura de que su MEV no pueda ser robado. Finalmente, los atestiguadores validan este nuevo bloque.
Diseño de ePBS de "dos ranuras"
Un modelo recién lanzado es similar al enfoque de dos ranuras pero introduce un comité de puntualidad de carga útil. Primero, se selecciona y se compromete a la oferta de un constructor por el proponente, y luego el comité de validadores da su testimonio. Posteriormente, el constructor revela la carga útil del bloque (sus transacciones), y el comité de puntualidad de carga útil confirma que la carga útil se proporcionó a tiempo y su validez. Las otras diferencias entre estos dos métodos radican en los detalles de las operaciones de Prueba de Participación de Ethereum, pero eso está más allá del alcance de esta publicación.
Diseño de ePBS con un Comité de Oportunidad de Carga
Otro diseño gira en torno al concepto de una subasta de ranuras. Aquí, los constructores, durante su oferta, se comprometen a una ranura en la época sin especificar el bloque. Básicamente se comprometen a crear un bloque durante su ranura asignada, ofreciendo un cierto precio para hacerlo. Esto ofrece adaptabilidad, especialmente para el MEV de dominio cruzado que requiere acción en tiempo real.
Hasta ahora, todos los diseños de ePBS otorgan al constructor un control total sobre las transacciones del bloque. Una solución alternativa potencial es el uso de una lista de inclusión. Esta lista, enviada por el proponente al constructor, idealmente todas las transacciones actualmente en el mempool o no necesariamente, contiene transacciones que deben formar parte del bloque del constructor si hay espacio. Si el bloque del constructor está lleno, deben indicarlo, confirmando que han recibido la lista. Este método fortalece la resistencia a la censura de la red. Si un constructor quiere censurar una transacción, con el tiempo será difícil y costoso hacerlo. Debido a EIP 1559, los bloques llenos de forma consecutiva harán que la tarifa base aumente exponencialmente. Por lo tanto, si un constructor censura continuamente una transacción llenando un bloque con transacciones falsas, los costos crecientes hacen que esto sea inviable con el tiempo.
Puede haber casos en los que el proponente desee tener cierta influencia en la creación de bloques. Otra característica de ePBS podría implicar que el proponente haga una sección del bloque (ya sea al principio o al final) y delegue el resto a un constructor. Todos estos diseños y características no son mutuamente excluyentes, se trata más de equilibrar sus beneficios y desventajas.
El Enfoque de Reenvío OptimistaOtra versión de ePBS aprovecha nuestros relés de confianza existentes. La idea es reducir gradualmente las responsabilidades del relé hasta que sirva principalmente como un optimizador, en lugar de un componente crucial. En su primera fase, eliminamos el deber del relé de verificar la validez del bloque. Esto reduce en gran medida el costo de ejecutar un relé, ya que ya no es necesaria la simulación de bloques para garantizar su validez. Además, agiliza la función del relé, reduciendo entre 100 y 200 milisegundos de latencia en sus comunicaciones con los proponentes y constructores. Entonces, ¿cómo nos aseguramos de que el proponente reciba su pago si un bloque resulta no ser válido? Los constructores tendrían la obligación de depositar una garantía, igual a su oferta, cuando presenten ofertas. Si el bloque no es válido, la garantía cubre el pago que el proponente habría recibido. Este concepto se denomina Retransmisión Optimista V1.
Transmisión Optimista V1
Llevando el retransmisor optimista un paso más allá a la V2, podemos eliminar la necesidad de descargar el bloque del relé, reduciendo otros 50 a 100 milisegundos de latencia. Las mismas garantías se aplican: si un bloque nunca se descarga, el colateral del constructor paga.
Optimistic Relaying V2
En última instancia, el objetivo final de la Transmisión Optimista comienza a parecerse mucho al modelo del comité de puntualidad de carga que mencioné anteriormente. Aquí está la secuencia: Los constructores envían sus ofertas en una capa peer to peer. El proponente acepta una oferta y la sigue con un encabezado firmado. Luego, el constructor despliega el bloque. En esta etapa, el único trabajo del relé es supervisar el mempool de la capa peer to peer, básicamente cronometrando cuándo ocurren diferentes actividades. El papel del relé se vuelve muy liviano, solo necesita mantenerse al tanto del mempool. Esto hace que el relé funcione de manera muy similar al comité de puntualidad de carga. Todos estos pasos avanzan hacia un futuro en el que el relé sea reemplazado por el comité de puntualidad de carga, optimizando todo el protocolo.
Aprovechando a los constructores para mejoras adicionales en el protocoloPBS surgió como una respuesta de Flashbots a los efectos de centralización de MEV, con el objetivo de intentar aprovechar MEV para obtener resultados positivos. Dado el nuevo rol en Ethereum especializándose en la construcción de bloques, hay una oportunidad para que estas entidades actúen como supercomputadoras, contrastando con los validadores ligeros. Se están desarrollando diseños de protocolos que capitalizan en estos constructores poderosos. La idea es mantener a los validadores simples y directos (algunos incluso podrían decir cucks) , mientras que los constructores, que no tienen tales restricciones, pueden funcionar a un nivel computacional mucho más alto. Una aplicación principal para estos constructores mejorados es la escalabilidad.
El diseño Danksharding del investigador de Ethereum Dankrad Feist sugiere que estos constructores altamente intensivos en recursos pueden construir un gran bloque que contiene todos los datos. Estos datos se segmentan y se comprometen mediante múltiples compromisos KZG. Construir este bloque requiere recursos considerables, pero validarlos es relativamente económico. Los validadores ligeros pueden aplicar luego el Muestreo de Disponibilidad de Datos para inspeccionar una pequeña sección del bloque y estar casi seguros de la accesibilidad de todo el conjunto de datos, lo que resulta en un aumento adicional de ~16 veces en el rendimiento de datos de Proto-Danksharding. Las complejidades de Danksharding son complicadas y no se cubren aquí, pero el punto clave es que estos constructores avanzados pueden delegar roles adicionales para mejorar aún más la red.
Otra idea para aprovechar los constructores es la posible realización de rollups basados. Hace unos años, Vitalik discutió modelos de secuenciación de rollup, acuñando el término Total Anarchy para uno de ellos, en el que cualquiera puede publicar un bloque de rollup y la primera secuencia que llega a la cadena es el bloque oficial. Este enfoque tenía muchas desventajas, como el spam en cadena y la ambigüedad sobre la secuencia ganadora. Sin embargo, el artículo reciente de Justin Drake sobre rollups basadosdestacó una estrategia más eficiente aprovechando a los constructores. En este modelo, el constructor en la capa uno funciona como el secuenciador de rollup, seleccionando selectivamente la secuencia óptima para incluir en la cadena. Esto garantiza que solo se incorporen las secuencias óptimas.
Más allá de los rollups, la introducción de constructores poderosos puede impulsar otras estructuras innovadoras, como clientes sin estado. Permiten que los nodos operen como de costumbre pero sin la carga de preservar estados obsoletos. Esto permite que los nodos sean más ligeros y dependan de la capacidad del constructor para generar pruebas criptográficas específicas.
PEPC: Protocol-Enforced Proposer CommitmentsLos compromisos de proponentes forzados por protocolo (PEPC, pronunciado pepsi) es un concepto introducido por el investigador de la Fundación Ethereum Barnabé Monnot en octubre de 2022. Puedes profundizar en la publicación original de Barnabéaquí. En su núcleo, PEPC tiene como objetivo otorgar a los proponentes un mayor poder en la construcción de bloques, que han perdido al vender la tarea completa a constructores especializados. En PEPC, los proponentes pueden agregar condiciones adicionales para que un bloque sea considerado válido, aparte de los requisitos habituales de Ethereum. Si un bloque no cumple con alguna de estas condiciones adicionales, se considera inválido y los validadores deben rechazarlo. Esto difiere de los compromisos de EigenLayer, donde los validadores con compromisos adicionales pueden perder alguna cantidad de ETH apostado por incumplimiento o ser recompensados por cumplir con ellos. Sin embargo, el bloque sigue siendo válido independientemente de estos compromisos.
Imagina que Alice es una proponente en la red Ethereum. Con PEPC, Alice tiene la flexibilidad de hacer un compromiso específico para el próximo bloque. Podría comprometerse a que su bloque contendrá al menos tres transacciones relacionadas con un contrato inteligente en particular, y está dispuesta a asignar el 70% del gas del bloque para estas. Ella comunica este compromiso, y se convierte en parte de las condiciones de validez de su bloque. Ahora, Bob, un Constructor, ve el compromiso de Alice. Empaqueta un conjunto de transacciones que cumplan con los criterios de Alice y se lo envía. Si el bloque de Alice, después de ser construido, se alinea con su compromiso (es decir, contiene las transacciones especificadas que consumen el gas designado), entonces el bloque se considera válido y puede agregarse a la cadena de bloques. Si no, el bloque de Alice no será aceptado, asegurando que ella cumple con sus compromisos declarados.
Una diferencia clave entre ePBS y PEPC radica en la naturaleza de los compromisos. En ePBS, los proponentes y constructores siguen un procedimiento fijo y uniforme. Es una especie de enfoque de talla única para todo. Un proponente se compromete con un hash de bloque específico, y el constructor luego produce una carga útil coincidente. Sin embargo, PEPC introduce variedad. Cada proponente puede establecer condiciones únicas, ofreciendo mucha más flexibilidad. Es crucial notar que la existencia de PEPC depende de ePBS, se complementan entre sí. Los detalles exactos de cómo funciona PEPC aún están en discusión e investigación.
ConclusiónPBS no es una implementación específica, es una filosofía de diseño. Dice que existen incentivos para la división del trabajo y que los actores del protocolo delegarán algunas responsabilidades a entidades externas más especializadas. El objetivo del protocolo es ofrecer una interfaz confiable, lo más desconfiada posible, para garantizar que esta delegación sea fluida, justa e inclusiva. Sin esto, algunos actores podrían tener ventaja, lo que llevaría a problemas de centralización observados por primera vez con MEV antes de la era de PBS. En su núcleo, PBS enfatiza la equidad y la descentralización. Si bien los elementos exactos que se integrarán en el protocolo se verán en futuras actualizaciones de Ethereum, el objetivo general de Ethereum sigue siendo claro: cómputo estatal accesible, abierto y confiable, supervisado por un grupo descentralizado de validadores ligeros.
Descargo de responsabilidad：- Este artículo ha sido reimpreso deEspejo]. Todos los derechos de autor pertenecen al autor original [Chaskin en cadena]. Si hay objeciones a esta reimpresión, por favor contacte al equipo de Gate Learn y ellos lo resolverán rápidamente.- Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.- 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.
