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: 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. Ranura: Una época consta de 32 espacios, que suman un total de . Época: 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 , tras las cuales es prácticamente imposible revertir los bloques. 2 épocas (aproximadamente 12,8 min) Comités 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 Sería inviable que tantos validadores tuvieran que verificar cada bloque cada 12 segundos. Por lo tanto, los validadores se dividen en para validar eficientemente las transacciones y certificar la validez del bloque. Ethereum beaconcha.in. comités 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 comités asignados por puesto y validadores en cada comité (donde > 128). Esto significa que hay atestaciones para cada puesto. Como comprenderá, puede resultar abrumador para la red compartir tantas atestaciones. N M M NxM Los agregadores de cada comité se encargan de agregar las certificaciones de su respectivo comité. Esto significa que, de un comité de validadores, solo hay una final en lugar de M Aggregated Attestation M En cada turno, se presentan atestaciones (una por cada comité de ese turno) que se discuten sobre el tema global. El proponente del siguiente turno recoge estas atestaciones. N N 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 comités por espacio, es decir, 64 N=64 Propuesta anticipada La reorganización de la cadena de balizas está diseñada para proporcionar un mínimo de de anticipación en las próximas asignaciones del comité del validador para la certificación, según la reorganización y el espacio. que esta anticipación no aplica a las propuestas, que deben verificarse durante la época en cuestión. 1 época (32 espacios) Tenga en cuenta Se puede llamar al inicio de cada época para obtener la asignación de la siguiente época ( ). Esto también permite a los validadores calcular el ID de subred, unirse al comité correspondiente y estar preparados para sus tareas. get_committee_assignment current_epoch + 1 Además, un Validador podría ser asignado como de un comité específico. De ser así, también deberá suscribirse al tema correspondiente. Aggregator Responsabilidades del proponente Dentro de cada espacio, se selecciona un como para crear y enviar un bloque. único validador del comité respectivo proponente El papel del proponente es crucial ya que: Construya un bloque incluyendo transacciones y certificaciones pendientes. Firme y transmita el a la red. SignedBeaconBlock 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: : 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. Adelantamiento : ejecutar una transacción inmediatamente después de un evento específico (por ejemplo, bots de arbitraje). Back-running : una combinación de ataques frontales y retrógrados, especialmente en operaciones DeFi. Ataques sándwich ¿Quién extrae MEV? : 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. Validadores (Pre-PBS) : actores independientes que escanean el mempool en busca de oportunidades MEV y envían transacciones en consecuencia. Buscadores : 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. Constructores (Post-PBS) 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 . Esto creó un ecosistema donde el MEV era extraído directamente por validadores o subcontratado a buscadores especializados. control total sobre el orden de las transacciones Cómo funcionaba antes de PBS: : las transacciones se transmiten como de costumbre y entran al pool de memoria. Pool de transacciones Los validadores seleccionan cuidadosamente las transacciones del mempool. Estas podrían ordenarse según la , 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). priority_fee El validador construye el bloque basándose en las transacciones que seleccionó. : el bloque firmado se transmite a la red. Propagación de bloque 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 : 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. Centralización de la energía MEV : los validadores podrían optar por excluir transacciones que no se alineen con sus incentivos financieros. Mayor riesgo de censura : 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. Congestión de la red y tarifas de gas elevadas 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 . PBS divide las responsabilidades de la producción de bloques entre dos entidades independientes: la Separación Proponente-Constructor (PBS) : entidades especializadas en la construcción de bloques optimizados, que a menudo incorporan estrategias MEV. Constructores de bloques : Los validadores ya no construyen bloques por sí mismos; simplemente seleccionan el bloque más rentable ofrecido por los constructores. Proponentes de bloques (validadores) Cómo funciona después de PBS: : los constructores de bloques compiten para construir el bloque más rentable, teniendo en cuenta las oportunidades de extracción de MEV. Los constructores construyen bloques : los constructores pujan para proponer su bloque a los validadores, garantizando así que estos reciban la opción más rentable. Pujas para la inclusión de bloques : en lugar de seleccionar transacciones individuales, los validadores simplemente eligen el bloque de construcción con la oferta más alta, maximizando sus recompensas. Los validadores seleccionan la oferta más alta Cómo funciona ahora la construcción de bloques de Ethereum El usuario envía la transacción a través de una billetera conectada JSON-RPC. Esta transacción se envía al mempool público. Todas las transacciones se almacenan aquí antes de ser recogidas y validadas. Recientemente, 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 para obtener más información. los flujos de órdenes privados Dune → entidades externas que escanean el mempool continuamente para encontrar oportunidades de MEV ( ). 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 . Buscadores más información a continuación eth_sendBundle : 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. Nota → 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. Constructores Rellenan los bloques con: Paquetes enviados por los Buscadores. Transacciones de alta prioridad. Ordenar las transacciones generales teniendo en cuenta maximizar los ingresos. También configuran el campo 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. feeRecipient : Los constructores son entidades externas y no interactúan directamente con la cadena de bloques. Nota → 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 y 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 . Relés BeaverBuild Titan. 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 . 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 . El Retransmisor envía ahora un que contiene el hash del cuerpo, la puja y la firma del constructor. feeRecipient eth_getPaylaodHeader PayloadHeader El proponente tiene 2 opciones en este punto: Para seleccionar el (también llamado ) proporcionado por el Relé, el proponente debe firmar el encabezado con su clave y enviarlo de vuelta al Relé. Posteriormente, solicita el mediante la llamada . El Relé ejecuta la llamada , que devuelve el 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. PayloadHeader Bloque Ciego PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload El Proponente puede optar por no aceptar el 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. PayloadHeader 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 por esta misma razón. Antes de enviar el encabezado, el relé envía el a un para su custodia. Una vez que el relé recibe el firmado del proponente, verifica la firma y envía el 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. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Nota Es una infracción sancionable firmar dos titulares diferentes para el mismo puesto de propuesta. 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 los bloques creados por Builders solo incluyen entre el 0 y el 7 % de las transacciones sancionadas por la OFAC. Censorship.pics, ¿Cómo solucionamos esto? Una de las soluciones más conocidas para la censura de transacciones al momento de escribir esto son . Inclusion Lists 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 inclusiones 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. : También existe el concepto de LI) que realiza IL para el Bloque N actual. Sin embargo, este diseño presentó fallas económicas que llevaron a Nota Listas de Inclusión Local ( las Listas de Inclusión Avanzada (FID). 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 son un nuevo diseño propuesto en 2024 que desarrolla y mejora las Listas de Inclusión para aumentar la neutralidad creíble. Las Listas de Inclusión Forzada de Elección de Bifurcación (FOCIL) 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». : Los miembros del comité de IL no pueden garantizar ningún tipo de orden de transacción, ya que las transacciones de IL pueden incluirse en cualquier orden. Solo garantizan la inclusión de las transacciones. Nota Beneficios de PBS para la gestión de vehículos eléctricos : 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. Descentralización de la extracción de MEV : 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. Distribución de ingresos más justa : la competencia entre constructores conduce a bloques optimizados con mejor eficiencia de gas. Utilización más eficiente del espacio en bloques Desafíos de PBS : si bien los validadores están descentralizados, algunos constructores dominantes aún podrían centralizar la extracción de MEV. Riesgo de centralización entre los constructores : 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. Confianza en los relés MEV fuera de la cadena 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 Gracias a , y por revisar y brindar sugerencias. @mteam @Gajpower @unnawut
