TL;DR

• ePBS está diseñado con un enfoque en la seguridad del Constructor, otorgando a los Constructores un control total sobre las transacciones de bloques.
• Integra la Separación de Propositor-Constructor (PBS) directamente en la capa de consenso de Ethereum, conocida como PBS In-Protocol, para abordar posibles fallas de relé y eliminar los puntos únicos de falla del sistema.
• ePBS continúa la base de PBS al reducir el control de una sola entidad sobre el contenido del bloque, mejorando la resistencia a la censura y la descentralización de la red.
• El Comité de Oportunidad de Carga (PTC) garantiza la oportunidad y validez de las transacciones en los nuevos bloques.

Introducción

En febrero, el desarrollador de Prysm, Potuz, planteó preocupaciones sobre problemas de confianza en la red principal de Ethereum, sugiriendo un retraso en la bifurcación de Electra hasta 2025, utilizando el Evento de Interoperabilidad para refinar el diseño de ePBS. Sin embargo, hubo opiniones encontradas dentro de la comunidad de Ethereum, con algunos desarrolladores e investigadores preocupados por los posibles riesgos. Las opiniones sobre ePBS están divididas, así que hoy exploraremos qué es ePBS y cómo difiere de PBS.

Anteriormente, mencionamos que el mecanismo de PBS garantiza la seguridad del compromiso del Proponente y la explicación del Constructor al asignar esta responsabilidad a relés de confianza. Los relés almacenan el contenido del bloque y aseguran que el Proponente reciba el contenido del bloque pero no pueda robar fácilmente el contenido del Constructor. Sin embargo, si el relé es malicioso, tanto el Proponente como el Constructor pueden resultar perjudicados, y solo pueden cambiar a otro relé y esperar que no sea malicioso. Esto presenta un problema: debemos encontrar un tercero de confianza para la delegación. PBS es una solución fuera de la cadena que depende del consenso de la comunidad y de la conformidad voluntaria, lo que requiere una coordinación y confianza adicionales.

En PBS, debe haber un rol intermediario que actúe como un administrador de confianza de terceros:

• Los proponentes deben confiar en el intermediario si desean vender los derechos de contenido de bloque.
• Los constructores deben confiar en el intermediario si desean comprar derechos de construcción de bloques.

Diseño Revolucionario de ePBS

Separación Incorporada del Constructor de Propositor

El Separación de Propositor-Constructor consagrado (ePBS) es una variante de PBS integrada directamente en la capa de consenso de Ethereum, también conocida como PBS en Protocolo. Fue diseñado para abordar posibles fallos de retransmisión y eliminar puntos únicos de fallo del sistema. Como un mecanismo de consenso emergente, ahora nos adentraremos en ePBS, explicando sus principios fundamentales, ventajas y cómo difiere del Separación tradicional de Propositor-Constructor (PBS).

PBS reemplaza la necesidad de un rol de intermediario de confianza utilizando el propio protocolo de Ethereum. Si tanto el Proposer como el Builder actúan de manera malintencionada, el protocolo de Ethereum puede imponer sanciones (como la confiscación), eliminando la dependencia de confiar en un rol de terceros. Esta es la diferencia principal de PBS, donde la confianza es externa.

A pesar de esto, la separación de roles en ePBS aún sigue la estructura original de PBS, reduciendo el control de una sola entidad sobre el contenido de los bloques, mejorando así la resistencia a la censura y la descentralización de la red blockchain.

• Propositor: Responsable de proponer el bloque, incluyendo la información del encabezado del bloque.
• Constructor: Responsable de construir el contenido del bloque.

Dos Grandes Beneficios

Castigo directo por acciones maliciosas y no se necesita confianza de terceros

A partir de su nombre, es evidente que el término 'Enshrined' en ePBS refleja su diseño integrado de protocolo, permitiendo el castigo directo por comportamiento malicioso. Esta integración transforma sutilmente el modelo de confianza dentro del sistema.

1. Capacidad incorporada para detección y cumplimiento

   En PBS, la identificación y penalización de acciones maliciosas depende de la intervención de terceros, como validadores o relés. En cambio, ePBS, al ser nativo del protocolo, permite que el propio protocolo detecte y maneje directamente el mal comportamiento sin requerir intervención externa.

2. Reducida dependencia de terceros, mejorando la descentralización

   PBS depende inherentemente de la gobernanza externa o de terceros, lo que introduce un elemento de centralización de la confianza. Sin embargo, ePBS incorpora reglas dentro del protocolo, reduciendo fundamentalmente la dependencia de la confianza externa. Este cambio mejora la descentralización del sistema, haciéndolo más robusto y resistente a la manipulación.

*Comparación entre PBS tradicional y ePBS👇

ePBS Design

La Danza de Ejecución y Verificación

En el sistema de Prueba de Participación (PoS) de Ethereum, el tiempo para cada intervalo se divide en intervalos de 12 segundos. En cada intervalo, se elige al azar un validador para proponer un bloque y se asigna un comité para verificar la validez del bloque. Si no se propone un bloque durante el intervalo dado, el validador responsable verificará el bloque anterior después de 4 segundos.

Fuente: ethresearch, una ranura ePBS será procesada por la Capa de Consenso (CL) y la Capa de Ejecución (EL). La información del bloque se transmite en la capa de consenso y luego el bloque se envía a la capa de ejecución para su verificación.

1. Fase de Subasta en Bloque: El Constructor comienza a hacer ofertas y envía la oferta al Propositor.
2. Difusión del proponente: el proponente selecciona la oferta ganadora y decide si utilizar la Lista de inclusión para construir el contenido del bloque, luego difunde el bloque.
3. Votación del validador: Al ver el bloque, los validadores votan en función de los resultados de su verificación.
4. Atestación Agregada: Las atestaciones agregadas son creadas por los Agregadores, quienes combinan las pruebas de múltiples validadores para el mismo bloque. Los validadores luego utilizan la atestación agregada para verificar el bloque.
5. Transmisión de carga útil: El constructor debe publicar la carga útil de ejecución completa dentro del tiempo designado.
6. Votación PTC: El Comité de Puntualidad de Carga (PTC) supervisa y verifica si la carga del Constructor es oportuna y válida.
7. El Proponente de la siguiente ranura publica su bloque, construyéndolo sobre un bloque lleno o vacío basado en los resultados de votación del PTC y las atestaciones agregadas. Un bloque con un mayor porcentaje de votos PT oportunos se considera un bloque lleno.

PTC - Garantizando la puntualidad y validez de las transacciones en nuevos bloques \El Comité de Oportunidad de Carga Útil (PTC) asegura que las transacciones en los nuevos bloques se agreguen de manera oportuna y precisa. Este comité consta de validadores (521 miembros prestados del comité de la cadena de balizas), que verifican si el Constructor ha completado el llenado de transacciones del bloque y si estas transacciones se ejecutan correctamente de acuerdo con las reglas antes del final de cada ciclo de creación de bloque.

En términos simples, el PTC actúa como un equipo supervisor, asegurándose de que el Constructor presente su trabajo a tiempo e incluya las transacciones correctas en el bloque. Si el Constructor lo hace bien y presenta el bloque requerido a tiempo, el PTC lo confirma mediante votación. De esta manera, la red puede identificar qué bloques están completos y son válidos y cuáles pueden tener problemas o estar incompletos.

A través del mecanismo de votación, el PTC influye en si un bloque se considera un 'bloque completo' o un 'bloque vacío'. Si el PTC verifica la puntualidad y corrección de la carga útil, el bloque se reconoce como un 'bloque completo'. Si no hay carga útil o la carga útil está retrasada, el bloque puede ser marcado como un 'bloque vacío'. Según el voto del PTC, la red recompensa o castiga directamente al Propositor y Constructor para incentivar la construcción de bloques oportuna y precisa.

• Bloque completo: El bloque contiene un conjunto completo de carga útil válida, potencialmente incluyendo múltiples transacciones, y el estado de ejecución de las transacciones se actualiza de manera oportuna.
• Bloque vacío: El bloque contiene muy pocas o ninguna transacción en absoluto. Puede ser un bloque CL, pero no actualiza el estado EL.
• Bloque faltante: Un espacio está vacío. Esto se refiere a un bloque que se esperaba pero no se creó o se agregó con éxito a la cadena. Los bloques faltantes pueden clasificarse como completos o vacíos en función del voto de elección de bifurcación (bloque, espacio).

La resistencia a la censura de ePBS, combinada con el diseño de la lista de inclusión

Si bien el diseño central de ePBS gira en torno a la seguridad del Constructor y otorga a los Constructores el control total sobre las transacciones de bloques, la implementación de la Lista de Inclusión lo convierte en una combinación perfecta para lograr resistencia a la censura y descentralización.

En nuestros artículos anteriores, discutimos el CLproceso (para más detalles, por favor visita: https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rgEn resumen, el Proponente proporciona al Constructor una lista de transacciones que deben tener prioridad. Esta lista debe incluir todas las transacciones actualmente activas, independientemente de si están en la piscina de transacciones. Mientras haya espacio disponible en el bloque, las transacciones de la lista deben incluirse en el bloque del Constructor. Si el bloque está lleno, el Constructor debe indicar claramente y confirmar que ha reconocido la lista.

Cuando un Builder intenta censurar ciertas transacciones, la tarifa base aumentará rápidamente debido a la implementación de EIP-1559, ya que los bloques se llenan continuamente con transacciones. Si el Builder insiste en agregar transacciones falsas al bloque para realizar la censura, las tarifas crecientes harán que tales acciones sean prohibitivas e imprácticas.

Resumen

ePBS separa los roles de Proposer y Builder a través de su integración de protocolo. Con el PTC actuando como un subconjunto del comité de verificación, es responsable de votar sobre la validez y puntualidad de la Carga de Ejecución liberada por el Builder. La ventaja principal de ePBS radica en su cambio de depender de terceros de confianza a ser supervisado y penalizado directamente por el propio protocolo Ethereum, reduciendo la necesidad de confiar en una sola entidad. Esto no solo mejora la resistencia a la censura del sistema, sino que también fortalece la protección de transacciones a través de mecanismos como la Lista de Inclusión, haciendo que el costo de censurar transacciones sea prohibitivamente alto e impráctico.

Es importante tener en cuenta que ePBS proporciona una opción para la separación entre el proponente y el constructor de bloques a nivel de protocolo, en lugar de ser obligatorio. La distinción clave entre ePBS y otros modelos está en sus mecanismos de pago y modelos de confianza. Al considerar los problemas de confianza de todo el protocolo, el costo a pagar es la necesidad de comprometerse a pagar tarifas por adelantado. Por el contrario, MEV-Boost permite realizar pagos al proponente de balizas en función de las ganancias derivadas de la carga útil de ejecución secuenciada, lo que ofrece más espacio para la rentabilidad. Tal vez algún día, el ePBS pueda evolucionar hasta un punto en el que los compromisos de tarifas por adelantado ya no sean necesarios, ¡esta es una pequeña esperanza para el futuro!

Referencia

@ttsao/epbs-faq0"">https://hackmd.io/@ttsao/epbs-faq0

@potuz/rJ9GCnT1C"">https://hackmd.io/@potuz/rJ9GCnT1C

https://mirror.xyz/ohotties.eth/kw_7qbkOl4NV1pmpRgVwtsS-7TZff_zTmmNEOm2BbmU

https://mirror.xyz/barnabe.eth/LJUb_TpANS0VWi3TOwGx_fgomBvqPaQ39anVj3mnCOg

https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe

@potuz/ry9NirU2p"">https://hackmd.io/@potuz/ry9NirU2p

https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

https://ethresear.ch/t/three-dichotomies-in-epbs/16267

https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770?utm_source=substack&utm_medium=email

Descargo de responsabilidad：

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