Construcción de bloques de Ethereum: la economía oculta detrás de cada transacción

La construcción de bloques es un aspecto crucial del ciclo de vida de Ethereum, que consta de varios componentes. Determina qué transacciones se incluyen en un bloque y en qué orden, lo que impacta directamente en la eficiencia, la descentralización y la equidad de la red. Con el tiempo, el proceso de producción de bloques de Ethereum ha evolucionado, especialmente con el creciente papel de MEV y la transición de la selección basada en validadores a constructores especializados.

Esta publicación discutirá cómo ha evolucionado la construcción de bloques de Ethereum junto con la introducción de la separación de proponentes y constructores y la investigación futura.

Introducción a los componentes de construcción de bloques de Ethereum

Ranuras y épocas

Ethereum organiza el tiempo en unidades discretas:

• Ranura: Una ranura es un periodo de 12 segundos en el que se puede proponer un solo bloque. Si ningún validador envía un bloque dentro de una ranura, este se omite.
• Época: Una época consta de 32 espacios, que suman un total de 6,4 minutos .

Al final de cada época, las funciones del validador se redistribuyen para garantizar la descentralización y la seguridad. Ethereum alcanza su finalidad económica tras 2 épocas (aproximadamente 12,8 min) , tras las cuales es prácticamente imposible revertir los bloques.

Comités

Ethereum cuenta con una gran cantidad de validadores en la red. Al momento de escribir este artículo, hay 1,051,349 validadores activos según beaconcha.in. Sería inviable que tantos validadores tuvieran que verificar cada bloque cada 12 segundos. Por lo tanto, los validadores se dividen en comités para validar eficientemente las transacciones y certificar la validez del bloque.

Cada comité:

• Consiste en un subconjunto de validadores asignados aleatoriamente al comienzo de una época utilizando RANDAO.
• Garantiza que ningún validador tenga una influencia desproporcionada.
• Participa en la votación (certificación) de los bloques y confirma su validez.

El tamaño de un comité depende del número total de validadores activos en la red, pero generalmente cada comité tiene al menos 128 validadores.

En cada ranura:

• Digamos que hay N comités asignados por puesto y M validadores en cada comité (donde M > 128). Esto significa que hay NxM atestaciones para cada puesto. Como comprenderá, puede resultar abrumador para la red compartir tantas atestaciones.

• Los agregadores de cada comité se encargan de agregar las certificaciones de su respectivo comité. Esto significa que, de un comité de M validadores, solo hay una Aggregated Attestation final en lugar de M

• En cada turno, se presentan N atestaciones (una por cada comité de ese turno) que se discuten sobre el tema global. El proponente del siguiente turno recoge estas N atestaciones.

  
  

Algunos puntos a tener en cuenta

• Durante una época, cada validador activo es miembro de exactamente un comité, por lo que todos los comités de la época están separados.

• El protocolo ajusta el número total de comités en cada época de acuerdo al número de validadores activos.

• El diseño actual es tener 64 comités por espacio, es decir, N=64

  
  

Propuesta anticipada

La reorganización de la cadena de balizas está diseñada para proporcionar un mínimo de 1 época (32 espacios) de anticipación en las próximas asignaciones del comité del validador para la certificación, según la reorganización y el espacio. Tenga en cuenta que esta anticipación no aplica a las propuestas, que deben verificarse durante la época en cuestión.

Se puede llamar get_committee_assignment al inicio de cada época para obtener la asignación de la siguiente época ( current_epoch + 1 ). Esto también permite a los validadores calcular el ID de subred, unirse al comité correspondiente y estar preparados para sus tareas.

Además, un Validador podría ser asignado como Aggregator de un comité específico. De ser así, también deberá suscribirse al tema correspondiente.

Responsabilidades del proponente

Dentro de cada espacio, se selecciona un único validador del comité respectivo como proponente para crear y enviar un bloque.

El papel del proponente es crucial ya que:

• Construya un bloque incluyendo transacciones y certificaciones pendientes.
• Firme y transmita el SignedBeaconBlock a la red.
• Gana recompensas por proponer bloques válidos con éxito.

Breve introducción al MEV

MEV es la ganancia adicional que extraen los validadores (anteriormente mineros) al reordenar, incluir o censurar las transacciones dentro de un bloque.

Algunas estrategias MEV comunes son:

• Adelantamiento : Colocar una operación justo antes de una transacción rentable. El adelanto también se considera un MEV tóxico, ya que sorprende al usuario con un efecto negativo.
• Back-running : ejecutar una transacción inmediatamente después de un evento específico (por ejemplo, bots de arbitraje).
• Ataques sándwich : una combinación de ataques frontales y retrógrados, especialmente en operaciones DeFi.

¿Quién extrae MEV?

• Validadores (Pre-PBS) : Cuando los validadores controlaban la producción de bloques, tenían total discreción sobre el orden de las transacciones y podían extraer MEV directamente.
• Buscadores : actores independientes que escanean el mempool en busca de oportunidades MEV y envían transacciones en consecuencia.
• Constructores (Post-PBS) : Después de PBS, los constructores de bloques asumen el rol de construir bloques optimizados para MEV, mientras que los validadores simplemente seleccionan bloques del mejor postor.

Construcción de bloques pre-PBS: MEV centrado en el validador

Antes de la transición de Ethereum a PBS, el proponente (anteriormente mineros en PoW) tenía control total sobre el orden de las transacciones . Esto creó un ecosistema donde el MEV era extraído directamente por validadores o subcontratado a buscadores especializados.

Cómo funcionaba antes de PBS:

1. Pool de transacciones : las transacciones se transmiten como de costumbre y entran al pool de memoria.
2. Los validadores seleccionan cuidadosamente las transacciones del mempool. Estas podrían ordenarse según la priority_fee , que corresponde a las tarifas que el usuario está dispuesto a pagar para ser incluido primero. También podrían ordenarse de forma que el validador genere más ingresos (mediante la administración de sándwiches o la ejecución anticipada).
3. El validador construye el bloque basándose en las transacciones que seleccionó.
4. Propagación de bloque : el bloque firmado se transmite a la red.

Esto se ha resumido de forma un tanto vaga para simplificar. Pero este fue el flujo general. Esto se puede denominar " Construcción de Bloques Vainilla".

Problemas con la construcción de bloques antes de PBS

• Centralización de la energía MEV : los grandes validadores tenían una ventaja económica sobre los más pequeños debido a su capacidad de extraer MEV de manera más eficiente.
• Mayor riesgo de censura : los validadores podrían optar por excluir transacciones que no se alineen con sus incentivos financieros.
• Congestión de la red y tarifas de gas elevadas : las guerras de ofertas por las transacciones MEV llevaron a una utilización ineficiente del espacio de bloques, lo que aumentó los costos para los usuarios habituales.

Construcción de bloques después del PBS: separación de proponentes y constructores

Para abordar los riesgos de centralización y las ineficiencias de la construcción de bloques controlada por el validador, se introdujo la Separación Proponente-Constructor (PBS) . PBS divide las responsabilidades de la producción de bloques entre dos entidades independientes:

1. Constructores de bloques : entidades especializadas en la construcción de bloques optimizados, que a menudo incorporan estrategias MEV.
2. Proponentes de bloques (validadores) : Los validadores ya no construyen bloques por sí mismos; simplemente seleccionan el bloque más rentable ofrecido por los constructores.

Cómo funciona después de PBS:

1. Los constructores construyen bloques : los constructores de bloques compiten para construir el bloque más rentable, teniendo en cuenta las oportunidades de extracción de MEV.
2. Pujas para la inclusión de bloques : los constructores pujan para proponer su bloque a los validadores, garantizando así que estos reciban la opción más rentable.
3. Los validadores seleccionan la oferta más alta : en lugar de seleccionar transacciones individuales, los validadores simplemente eligen el bloque de construcción con la oferta más alta, maximizando sus recompensas.

Cómo funciona ahora la construcción de bloques de Ethereum

1. El usuario envía la transacción a través de una billetera conectada JSON-RPC.
2. Esta transacción se envía al mempool público. Todas las transacciones se almacenan aquí antes de ser recogidas y validadas. Recientemente, los flujos de órdenes privados han cobrado protagonismo, y la mayoría de las grandes empresas los utilizan como alternativa a la difusión pública de sus transacciones mediante canales privados o con permisos. Consulte el panel de control de Dune para obtener más información.

3. Buscadores → entidades externas que escanean el mempool continuamente para encontrar oportunidades de MEV ( más información a continuación ). Extraen las transacciones correspondientes e insertan las suyas propias cuando es necesario para obtener ganancias. Luego, crean un paquete de estas transacciones, cuyo orden debe mantenerse para que el Buscador obtenga ganancias. Los paquetes son transacciones ordenadas que deben ejecutarse automáticamente. Junto con este paquete, pueden agregar una transacción al final que representa un "soborno" al Constructor. Este paquete se envía al Constructor mediante la llamada eth_sendBundle .

   Nota : Los buscadores son entidades externas e influyen en el orden de las transacciones, pero no participan en la validación de bloques ni en las decisiones de consenso.

   

   
   

4. Constructores → La siguiente entidad es el Constructor, quien construye el bloque. Busca maximizar tanto los ingresos por comisiones como los ingresos por MEV. Incluye las transacciones agrupadas enviadas por los Buscadores (con suerte, en orden) y acepta el pago (soborno) enviado por estos. Los Constructores construyen cargas útiles de ejecución utilizando las transacciones recibidas.

   Rellenan los bloques con:

   1. Paquetes enviados por los Buscadores.

   2. Transacciones de alta prioridad.

   3. Ordenar las transacciones generales teniendo en cuenta maximizar los ingresos.

      
      

   También configuran el campo feeRecipient con su propia dirección, lo que significa que recibirán tanto los sobornos del Buscador como todas las comisiones de las transacciones de su bloque enviado. Los Constructores envían una transacción al final de su bloque, que funciona como soborno para el proponente, similar a lo que el Buscador hizo para el Constructor.

   
   

5. Relés → El mercado de Constructores es competitivo, con diversos constructores que buscan que sus cargas útiles se finalicen para obtener las comisiones. Sin embargo, la mayoría de los bloques son construidos por algunos constructores de bloques reconocidos, como BeaverBuild y Titan. Para simplificar este proceso al Proponente, los Relés son entidades intermediarias que validan las cargas útiles enviadas por los distintos Constructores y seleccionan la que ofrece la mayor ganancia/oferta. La comunicación entre el Relés y el Proponente utiliza un ingenioso mecanismo similar a un "Commit and Reveal" para garantizar que el Proponente no engañe a todas las entidades hasta este punto. Más información aquí .

Poniéndolo todo junto

Comunicación del proponente de retransmisión

Es muy posible que, al recibir la carga útil del bloque, el proponente la desempaque, inserte sus transacciones, modifique el orden a su gusto y configure su propia dirección como feeRecipient . Esto implicaría que todas las entidades que participaron en el proceso de construcción del bloque hasta ahora (Buscador → Constructor → Retransmisor) serían engañadas o cometerían un robo de MEV. Para evitarlo, el Retransmisor envía solo el encabezado de la carga útil del bloque seleccionado. Esto ocurre cuando el proponente realiza la llamada eth_getPaylaodHeader . El Retransmisor envía ahora un PayloadHeader que contiene el hash del cuerpo, la puja y la firma del constructor.

El proponente tiene 2 opciones en este punto:

• Para seleccionar el PayloadHeader (también llamado Bloque Ciego ) proporcionado por el Relé, el proponente debe firmar el encabezado con su clave y enviarlo de vuelta al Relé. Posteriormente, solicita el PayloadBody mediante la llamada eth_returnSignedHeader . El Relé ejecuta la llamada eth_sendPayload , que devuelve el ExecutionPayload completo al proponente. El proponente simplemente propone este bloque a la red Ethereum Validator o, más específicamente, al comité al que se le ha asignado.

  
  

• El Proponente puede optar por no aceptar el PayloadHeader enviado por el Retransmisor, en cuyo caso deberá construir el bloque él mismo. Esto incluye encontrar oportunidades de MEV y ordenar las transacciones en consecuencia. Por supuesto, en este caso, el Proponente se queda con todos los ingresos provenientes de las tarifas + MEV. Sin embargo, esto no es tan sencillo como parece. Encontrar MEV y optimizar los ingresos requiere un gran esfuerzo computacional y existe la posibilidad de que el proponente no pueda construir el bloque a tiempo (12 segundos), por lo que se perderá una ranura. En este caso, el proponente podría ser eliminado de la red.

Pero en el Caso 1, ¿qué pasa si el Proponente no envía el bloque enviado por el Retransmisor?

Bueno, el proponente debe firmar el PayloadHeader por esta misma razón. Antes de enviar el encabezado, el relé envía el PayloadBody a un Escrow para su custodia. Una vez que el relé recibe el PayloadHeader firmado del proponente, verifica la firma y envía el PayloadBody almacenado en el depósito de garantía al proponente. Supongamos que el proponente no incluye este bloque. Construye su propio bloque, ignorando el orden establecido hasta el momento. En este caso, la firma no coincidirá, ya que los encabezados han cambiado.

El constructor ahora puede transmitir estos encabezados firmados conflictivos a la red y el proponente puede ser eliminado de la red.

¿Qué impide que los constructores censuren las transacciones?

Bueno, nada. La razón más común por la que los constructores podrían censurar una transacción es porque interactúa con direcciones OFAC . En resumen, las direcciones OFAC interactúan con transacciones que pueden tener repercusiones legales, algo que, obviamente, nadie querría tener sobre sus hombros.

Según Censorship.pics, los bloques creados por Builders solo incluyen entre el 0 y el 7 % de las transacciones sancionadas por la OFAC.

¿Cómo solucionamos esto?

Una de las soluciones más conocidas para la censura de transacciones al momento de escribir esto son Inclusion Lists .

Las listas de inclusiones son una lista de transacciones (junto con algo llamado Resumen) que publica el proponente del espacio N junto con la propuesta del bloque del espacio N.

Las listas de inclusión exigen que las transacciones de la lista se incluyan en el bloque N o en el bloque N+1; de lo contrario, el bloque N+1 será inválido. Se denominan listas de inclusión avanzada.

Por supuesto, este diseño de ILs no permitirá una resistencia a la censura del 100%, pero hay investigaciones activas en curso para fortalecer estas propuestas y muchas optimizaciones interesantes que se pueden aplicar para mejorar la estructura de incentivos.

FOCIL

Las Listas de Inclusión Forzada de Elección de Bifurcación (FOCIL) son un nuevo diseño propuesto en 2024 que desarrolla y mejora las Listas de Inclusión para aumentar la neutralidad creíble.

FOCIL permite que varios Validadores sugieran la Lista de Inclusión para una ranura específica. Para ser más precisos, se eligen 16 Validadores aleatoriamente en cada ranura para formar un Comité de Lista de Inclusión. Cada miembro forma su propio IL local y lo comparte con la red. El Proponente recopila y agrega las listas de inclusión locales disponibles para crear un IL final. Los diseños de IL son ligeros, ya que no es necesario reconstruir el bloque para incluir estas transacciones; simplemente se pueden añadir al bloque. La condición para que un Bloque cumpla con el requisito de validación de IL es: « El Bloque es válido si contiene todas las transacciones de todos los IL hasta que se complete».

Beneficios de PBS para la gestión de vehículos eléctricos

• Descentralización de la extracción de MEV : Los constructores de bloques, en lugar de unos pocos validadores grandes, gestionan la extracción de MEV, lo que reduce los riesgos de centralización de los validadores. Sin embargo, esto es un arma de doble filo, ya que, para mitigar la centralización de los validadores, hemos introducido la centralización de constructores, donde solo unos pocos constructores construyen un gran porcentaje de bloques.
• Distribución de ingresos más justa : los validadores aún se benefician de MEV sin participar directamente en la extracción, lo que hace que la producción de bloques sea más justa.
• Utilización más eficiente del espacio en bloques : la competencia entre constructores conduce a bloques optimizados con mejor eficiencia de gas.

Desafíos de PBS

• Riesgo de centralización entre los constructores : si bien los validadores están descentralizados, algunos constructores dominantes aún podrían centralizar la extracción de MEV.
• Confianza en los relés MEV fuera de la cadena : PBS actualmente depende de los relés MEV-Boost, que operan fuera de la cadena, lo que plantea posibles riesgos de seguridad como un punto de falla.

Referencias:

La separación entre proponentes y constructores de Ethereum: promesas y realidades

Estado de la investigación: resistencia a la censura en PBS

Censura de los constructores: el núcleo podrido de Ethereum

Wiki del EPF - PBS

Notas sobre PBS

Lista de inclusión hacia adelante

¿Quién gana las subastas de construcción de bloques de Ethereum y por qué?

FOCIL

Expresiones de gratitud