El núcleo del diseño de ePBS se basa en el concepto de seguridad del Constructor, que otorga al Constructor el control total de las transacciones de Bloquear.
ePBS es una propuesta para incorporar directamente PBS en la capa de consenso de ETH, conocida como PBS en el protocolo, con el objetivo de hacer frente a posibles fallas de Repetidor y eliminar los puntos únicos de falla del sistema.
ePBS sigue siguiendo la base de PBS original, aumentando la resistencia a la censura y la descentralización de la red a través de la capacidad de un solo ente de soltar el contenido de bloquear.
El Comité de Oportunidad de Carga (PTC), en su función de supervisión, garantiza la puntualidad y validez del contenido de las transacciones en los nuevos bloques.
Prefacio
En febrero, el desarrollador de Prysm, Potuz, consideró que la red principal de ETH tenía problemas de confianza y abogó por retrasar la bifurcación Electra hasta 2025 para mejorar el diseño de ePBS utilizando el evento Interop. Sin embargo, la comunidad de ETH tiene opiniones diferentes sobre ePBS y algunos desarrolladores e investigadores están preocupados por los riesgos que podría conllevar. En cuanto a ePBS, las opiniones son diversas. Hoy vamos a entender qué es ePBS y cuál es la diferencia con PBS.
Anteriormente mencionamos que el mecanismo de PBS es para garantizar la seguridad de las promesas del Proposer y la seguridad en la interpretación del Builder, por lo tanto, se delega este derecho a un Repetidor de confianza. El Repetidor es responsable de custodiar el contenido del Bloquear, asegurando que el Proposer reciba el contenido del Bloquear pero no pueda robar fácilmente el contenido del Bloquear del Builder. Sin embargo, si el Repetidor actúa con malicia, tanto el Proposer como el Builder resultarán perjudicados, y solo podrán recurrir a colaborar con otro Relay y esperar que el otro Repetidor no actúe con malicia. Aquí surge un problema, debemos encontrar un tercero de confianza para realizar una delegación de confianza, ya que PBS es una solución fuera del protocolo. PBS depende del Consenso de la comunidad y de la adhesión voluntaria, requiriendo coordinación adicional y confianza.
En PBS debe haber un papel de comisionista como tercera parte para manejar problemas de crédito:
El proponente que desee vender los derechos de contenido de Bloquear debe confiar en el comisionista.
Aquellos que deseen comprar los derechos de construcción de Bloquear deben confiar en el comisionista.
El diseño revolucionario de ePBS
Separación del proponente integrado - constructor
La separación enshrined proposer-builder (ePBS) es otra variante derivada de PBS. ePBS es una propuesta que integra directamente PBS en la capa de consenso de ETH, por lo que también se conoce como In-Protocol PBS. Su creación responde a la necesidad de hacer frente a posibles fallos en el repetidor y eliminar los puntos únicos de fallo en el sistema. Como un nuevo mecanismo de consenso, a continuación analizaremos ePBS en profundidad, con el objetivo de explicar sus principios fundamentales, ventajas y diferencias con la separación tradicional de proposer-builder (PBS).
ePBS, es decir, Proposer-Builder Separation, es un mecanismo incorporado en el protocolo blockchain. Reemplaza el rol de Relay que necesita confianza en el protocolo Ethereum. Si cualquiera de las partes, el Proposer o el Builder, actúa de manera maliciosa, el propio protocolo Ethereum puede imponer una penalización (slashing), en lugar de depender de la confianza en un rol específico. Esta es la mayor diferencia y distinción entre este protocolo y el protocolo PBS mencionado anteriormente.
Por supuesto, la separación de roles en la aplicación de ePBS sigue la base original de PBS, aumentando la resistencia a la censura y el grado de descentralización de la cadena de bloques mediante la liberación del control de contenido por parte de una sola entidad.
Proponente: Responsable de la propuesta de Bloquear, incluido el encabezado de bloquear
Builder: contenido específico de Bloquear
Dos grandes beneficios
Castigar directamente el comportamiento malicioso y no depender de terceros de confianza
Desde el nombre, se puede saber que en ePBS, Enshrined puede saber que debido a la incorporación del protocolo, también castigará directamente el comportamiento malicioso y el centro de confianza también cambia silenciosamente bajo esta configuración.
protocolo具备识别和处理能力，直接惩处
En PBS, la identificación y castigo de comportamientos malintencionados requiere la intervención de terceros (validadores, relés, etc.). En ePBS, debido a su diseño dentro del propio protocolo, los comportamientos malintencionados pueden ser identificados y procesados directamente por el propio protocolo.
Sin necesidad de confiar en terceros, aumenta el nivel de descentralización.
PBS en cierta medida depende de la gobernanza externa o de terceros, lo que plantea problemas de centralización de confianza. En cambio, ePBS, al escribir las reglas en el protocolo, reduce la necesidad de confiar en terceros externos desde el principio, aumentando así el nivel de descentralización del sistema.
*Comparación entre PBS tradicional y ePBS
Diseño de ePBS
La danza de ejecución y verificación
En el POS de Ethereum, el tiempo de ranura se divide en intervalos de 12 segundos. En cada ranura, se elige al azar un validadores para proponer un Bloquear. Al mismo tiempo, se designa un comité para verificar la validez del Bloquear. Si un Bloquear no se propone en la ranura dada, 4 segundos después, los validadores responsables de la prueba verificarán el Bloquear anterior.
source：ethresearch, un slot ePBS será procesado por CL (capa de consenso) y EL (capa de ejecución). La información de bloquear se transmite en la capa de consenso, luego se enviará a la capa de ejecución para su validación.
el proponente difunde: el Proponente elige Licitación y decide si utilizar la Lista de Inclusión para construir su propio contenido de Bloquear. Luego difunde el Bloquear.
Los validadores votarán según el resultado de la validación cuando vean Bloquear.
Prueba de agregación (Aggregate attestation): La prueba de agregación es creada por Agregadores, quienes agregan pruebas de múltiples validadores para el mismo Bloque. Los validadores validan las pruebas a través de la prueba de agregación.
payload broadcast: Builder needs to publicly disclose the complete execution payload (ution Payload) within the specified time.
Votación PTC: Comité especial para supervisar y verificar si el payload del Builder es oportuno y efectivo.
El Proposer del próximo slot publicará su Bloquear, construido sobre el resultado de la votación PTC y la prueba de agregación en un bloque completo o en un Bloque vacío. Cuando el porcentaje de PT oportuno en el recuento de votos de un Bloquear es más alto, se considerará como un Bloque completo.
PTC, supervisa la puntualidad y eficacia del contenido de transacciones en el nuevo bloque.
El Comité de Oportunidad de Carga (PTC), 'Comité de Oportunidad de Carga de Datos'. Su función principal es garantizar que el contenido de las transacciones en el nuevo Bloquear se agregue de manera oportuna y precisa. Este comité está compuesto por validadores (parte del Comité de Cadenas de Banderas con 521 personas prestadas al comité), cuyo trabajo consiste en verificar si el Builder ha completado el llenado de transacciones del Bloquear y si estas transacciones se ejecutan correctamente según las reglas antes de que finalice el período de creación del Bloquear.
En pocas palabras, PTC es como un equipo de supervisión que supervisa si el Builder ha presentado su trabajo a tiempo y si incluye el Bloquear correcto. Si el Builder lo hace bien y presenta el Bloquear requerido a tiempo, PTC lo confirmará mediante votación. De esta manera, la red puede saber qué Bloquear son completos y válidos, y cuáles pueden tener problemas o estar incompletos.
A través del mecanismo de votación, PTC afecta si el Bloquear se considera en estado de "bloque completo" o "bloque vacío". Si PTC verifica la puntualidad y corrección de la carga, el Bloquear puede considerarse en estado de "bloque completo"; si no hay carga o la carga se somete a latencia, el Bloquear puede ser marcado como "bloque vacío". Luego, según el resultado de la votación de PTC, la red recompensa o castiga directamente al Proposer y Builder para incentivar la construcción oportuna y precisa del Bloquear.
Bloque completo: Bloquear contiene un conjunto de carga útil válida, que también puede contener varias transacciones y el estado de ejecución de las transacciones se actualizará de inmediato.
Implementación de resistencia a la censura de ePBS, combinada con el diseño de la Lista de Inclusión
Aunque el núcleo del diseño de ePBS se construye en torno a la seguridad del Builder, le otorga al Builder un control total sobre las transacciones de Bloquear. Por lo tanto, sobre esta base, el uso de la Lista de Inclusión sería una forma perfecta de lograr una combinación resistente a la censura y de Descentralización.
Anteriormente en nuestros artículos mencionamos CL, describimos brevemente el proceso (para más detalles, haga clic en el enlace: undefined). ** Proporciona esta lista a Builder y prioriza estas transacciones. Debe incluir todas las transacciones activas actuales, ya sea que estén en la mempool o no. Si hay espacio disponible en el bloque, las transacciones de la lista deben ser incluidas en el bloque del Builder. Si el bloque está lleno, el Builder debe identificarlo claramente y confirmar que han tomado nota de esta lista.
Cuando el Builder intenta revisar ciertas transacciones, debido a la implementación de EIP-1559, el Bloquear que se llena constantemente con transacciones hará que la tarifa base Suba rápidamente. Si en este momento el Builder sigue insistiendo en revisar agregando transacciones falsas en el Bloquear, los costos en constante aumento harán que este comportamiento sea demasiado costoso y ya no sea práctico.
Resumen
ePBS separa los roles de proponente y constructor a través del protocolo incorporado. PTC, como un subconjunto del comité de pruebas, es responsable de votar la validez y puntualidad de la carga de ejecución presentada por el constructor. Su principal ventaja radica en que transforma el papel de un tercero de confianza en ser supervisado y sancionado por el propio protocolo de Ethereum, lo que reduce la necesidad de confiar en una entidad única. No solo mejora la resistencia a la censura del sistema, sino que también fortalece la protección de las transacciones a través de mecanismos como la lista de inclusión, lo que hace que el costo de censurar una transacción sea alto e impracticable.
Además, declarando que ePBS solo proporciona una opción de separación de Bloquear Proposer y Builder a nivel de capa de protocolo, no es obligatorio, y su mayor diferencia radica en el mecanismo de pago y el modelo de confianza. Al considerar el problema de confianza en toda la capa de protocolo, el costo que se debe pagar es el compromiso anticipado de los pagos. En comparación con ePBS, MEV-Boost puede decidir el monto a pagar al Beacon Proposer según los ingresos logrados en su propio ution Payload, con más ganancias y espacio. Quizás algún día, cuando el mecanismo de ePBS se implemente sin la necesidad de comprometerse anticipadamente con los pagos, tendré un poco de fantasía y expectativa.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Crisis de confianza实验 ePBS的protocolo内置
TL;DR
Prefacio
En febrero, el desarrollador de Prysm, Potuz, consideró que la red principal de ETH tenía problemas de confianza y abogó por retrasar la bifurcación Electra hasta 2025 para mejorar el diseño de ePBS utilizando el evento Interop. Sin embargo, la comunidad de ETH tiene opiniones diferentes sobre ePBS y algunos desarrolladores e investigadores están preocupados por los riesgos que podría conllevar. En cuanto a ePBS, las opiniones son diversas. Hoy vamos a entender qué es ePBS y cuál es la diferencia con PBS.
Anteriormente mencionamos que el mecanismo de PBS es para garantizar la seguridad de las promesas del Proposer y la seguridad en la interpretación del Builder, por lo tanto, se delega este derecho a un Repetidor de confianza. El Repetidor es responsable de custodiar el contenido del Bloquear, asegurando que el Proposer reciba el contenido del Bloquear pero no pueda robar fácilmente el contenido del Bloquear del Builder. Sin embargo, si el Repetidor actúa con malicia, tanto el Proposer como el Builder resultarán perjudicados, y solo podrán recurrir a colaborar con otro Relay y esperar que el otro Repetidor no actúe con malicia. Aquí surge un problema, debemos encontrar un tercero de confianza para realizar una delegación de confianza, ya que PBS es una solución fuera del protocolo. PBS depende del Consenso de la comunidad y de la adhesión voluntaria, requiriendo coordinación adicional y confianza.
En PBS debe haber un papel de comisionista como tercera parte para manejar problemas de crédito:
El diseño revolucionario de ePBS
Separación del proponente integrado - constructor
La separación enshrined proposer-builder (ePBS) es otra variante derivada de PBS. ePBS es una propuesta que integra directamente PBS en la capa de consenso de ETH, por lo que también se conoce como In-Protocol PBS. Su creación responde a la necesidad de hacer frente a posibles fallos en el repetidor y eliminar los puntos únicos de fallo en el sistema. Como un nuevo mecanismo de consenso, a continuación analizaremos ePBS en profundidad, con el objetivo de explicar sus principios fundamentales, ventajas y diferencias con la separación tradicional de proposer-builder (PBS).
ePBS, es decir, Proposer-Builder Separation, es un mecanismo incorporado en el protocolo blockchain. Reemplaza el rol de Relay que necesita confianza en el protocolo Ethereum. Si cualquiera de las partes, el Proposer o el Builder, actúa de manera maliciosa, el propio protocolo Ethereum puede imponer una penalización (slashing), en lugar de depender de la confianza en un rol específico. Esta es la mayor diferencia y distinción entre este protocolo y el protocolo PBS mencionado anteriormente.
Por supuesto, la separación de roles en la aplicación de ePBS sigue la base original de PBS, aumentando la resistencia a la censura y el grado de descentralización de la cadena de bloques mediante la liberación del control de contenido por parte de una sola entidad.
Dos grandes beneficios
Castigar directamente el comportamiento malicioso y no depender de terceros de confianza
Desde el nombre, se puede saber que en ePBS, Enshrined puede saber que debido a la incorporación del protocolo, también castigará directamente el comportamiento malicioso y el centro de confianza también cambia silenciosamente bajo esta configuración.
En PBS, la identificación y castigo de comportamientos malintencionados requiere la intervención de terceros (validadores, relés, etc.). En ePBS, debido a su diseño dentro del propio protocolo, los comportamientos malintencionados pueden ser identificados y procesados directamente por el propio protocolo.
PBS en cierta medida depende de la gobernanza externa o de terceros, lo que plantea problemas de centralización de confianza. En cambio, ePBS, al escribir las reglas en el protocolo, reduce la necesidad de confiar en terceros externos desde el principio, aumentando así el nivel de descentralización del sistema.
*Comparación entre PBS tradicional y ePBS
Diseño de ePBS
La danza de ejecución y verificación
En el POS de Ethereum, el tiempo de ranura se divide en intervalos de 12 segundos. En cada ranura, se elige al azar un validadores para proponer un Bloquear. Al mismo tiempo, se designa un comité para verificar la validez del Bloquear. Si un Bloquear no se propone en la ranura dada, 4 segundos después, los validadores responsables de la prueba verificarán el Bloquear anterior.
source：ethresearch, un slot ePBS será procesado por CL (capa de consenso) y EL (capa de ejecución). La información de bloquear se transmite en la capa de consenso, luego se enviará a la capa de ejecución para su validación.
PTC, supervisa la puntualidad y eficacia del contenido de transacciones en el nuevo bloque.
El Comité de Oportunidad de Carga (PTC), 'Comité de Oportunidad de Carga de Datos'. Su función principal es garantizar que el contenido de las transacciones en el nuevo Bloquear se agregue de manera oportuna y precisa. Este comité está compuesto por validadores (parte del Comité de Cadenas de Banderas con 521 personas prestadas al comité), cuyo trabajo consiste en verificar si el Builder ha completado el llenado de transacciones del Bloquear y si estas transacciones se ejecutan correctamente según las reglas antes de que finalice el período de creación del Bloquear.
En pocas palabras, PTC es como un equipo de supervisión que supervisa si el Builder ha presentado su trabajo a tiempo y si incluye el Bloquear correcto. Si el Builder lo hace bien y presenta el Bloquear requerido a tiempo, PTC lo confirmará mediante votación. De esta manera, la red puede saber qué Bloquear son completos y válidos, y cuáles pueden tener problemas o estar incompletos.
A través del mecanismo de votación, PTC afecta si el Bloquear se considera en estado de "bloque completo" o "bloque vacío". Si PTC verifica la puntualidad y corrección de la carga, el Bloquear puede considerarse en estado de "bloque completo"; si no hay carga o la carga se somete a latencia, el Bloquear puede ser marcado como "bloque vacío". Luego, según el resultado de la votación de PTC, la red recompensa o castiga directamente al Proposer y Builder para incentivar la construcción oportuna y precisa del Bloquear.
Implementación de resistencia a la censura de ePBS, combinada con el diseño de la Lista de Inclusión
Aunque el núcleo del diseño de ePBS se construye en torno a la seguridad del Builder, le otorga al Builder un control total sobre las transacciones de Bloquear. Por lo tanto, sobre esta base, el uso de la Lista de Inclusión sería una forma perfecta de lograr una combinación resistente a la censura y de Descentralización.
Anteriormente en nuestros artículos mencionamos CL, describimos brevemente el proceso (para más detalles, haga clic en el enlace: undefined). ** Proporciona esta lista a Builder y prioriza estas transacciones. Debe incluir todas las transacciones activas actuales, ya sea que estén en la mempool o no. Si hay espacio disponible en el bloque, las transacciones de la lista deben ser incluidas en el bloque del Builder. Si el bloque está lleno, el Builder debe identificarlo claramente y confirmar que han tomado nota de esta lista.
Cuando el Builder intenta revisar ciertas transacciones, debido a la implementación de EIP-1559, el Bloquear que se llena constantemente con transacciones hará que la tarifa base Suba rápidamente. Si en este momento el Builder sigue insistiendo en revisar agregando transacciones falsas en el Bloquear, los costos en constante aumento harán que este comportamiento sea demasiado costoso y ya no sea práctico.
Resumen
ePBS separa los roles de proponente y constructor a través del protocolo incorporado. PTC, como un subconjunto del comité de pruebas, es responsable de votar la validez y puntualidad de la carga de ejecución presentada por el constructor. Su principal ventaja radica en que transforma el papel de un tercero de confianza en ser supervisado y sancionado por el propio protocolo de Ethereum, lo que reduce la necesidad de confiar en una entidad única. No solo mejora la resistencia a la censura del sistema, sino que también fortalece la protección de las transacciones a través de mecanismos como la lista de inclusión, lo que hace que el costo de censurar una transacción sea alto e impracticable.
Además, declarando que ePBS solo proporciona una opción de separación de Bloquear Proposer y Builder a nivel de capa de protocolo, no es obligatorio, y su mayor diferencia radica en el mecanismo de pago y el modelo de confianza. Al considerar el problema de confianza en toda la capa de protocolo, el costo que se debe pagar es el compromiso anticipado de los pagos. En comparación con ePBS, MEV-Boost puede decidir el monto a pagar al Beacon Proposer según los ingresos logrados en su propio ution Payload, con más ganancias y espacio. Quizás algún día, cuando el mecanismo de ePBS se implemente sin la necesidad de comprometerse anticipadamente con los pagos, tendré un poco de fantasía y expectativa.