TL;DR

• ePBS é projetado com foco na segurança do Builder, concedendo aos Builders controle total sobre transações de bloco.
• Integra a Separação Proposer-Builder (PBS) diretamente na camada de consenso do Ethereum, denominada In-Protocol PBS, para lidar com possíveis falhas de retransmissão e eliminar pontos únicos de falha do sistema.
• ePBS continua a base da PBS ao reduzir o controlo de uma única entidade sobre o conteúdo do bloco, aumentando a resistência à censura da rede e a descentralização.
• O Comitê de Pontualidade de Carga (PTC) garante a pontualidade e validade das transações nos novos blocos.

Introdução

Em fevereiro, o desenvolvedor da Prysm, Potuz, levantou preocupações sobre questões de confiança na mainnet do Ethereum, sugerindo um adiamento do fork Electra até 2025, usando o Evento de Interoperabilidade para refinar o design do ePBS. No entanto, houve opiniões divergentes dentro da comunidade Ethereum, com alguns desenvolvedores e pesquisadores preocupados com os riscos potenciais. As opiniões sobre o ePBS estão divididas, então hoje vamos explorar o que é o ePBS e como ele difere do PBS.

Anteriormente, mencionamos que o mecanismo PBS garante a segurança do compromisso do Proponente e a explicação do Construtor, atribuindo essa responsabilidade a retransmissores confiáveis. Os retransmissores armazenam o conteúdo do bloco e garantem que o Proponente receba o conteúdo do bloco, mas não possa facilmente roubar o conteúdo do Construtor. No entanto, se o retransmissor for malicioso, tanto o Proponente quanto o Construtor podem ser prejudicados e só podem mudar para outro retransmissor e esperar que não seja malicioso. Isso apresenta um problema: devemos encontrar uma terceira parte confiável para a delegação. O PBS é uma solução off-chain que depende do consenso da comunidade e da conformidade voluntária, exigindo coordenação adicional e confiança.

No PBS, deve haver um papel intermediário para atuar como um manipulador de confiança de terceiros:

• Os proponentes devem confiar no intermediário se quiserem vender os direitos de conteúdo em bloco.
• Os construtores devem confiar no intermediário se quiserem comprar direitos de construção em bloco.

Design revolucionário do ePBS

Separação do Construtor de Proponente Incorporado

O Separador de Proponente-Construtor Consagrado (ePBS) é uma variante do PBS integrado diretamente na camada de consenso do Ethereum, também conhecido como In-Protocol PBS. Foi projetado para lidar com possíveis falhas de retransmissão e eliminar os pontos únicos de falha do sistema. Como um mecanismo de consenso emergente, iremos agora aprofundar-nos no ePBS, explicando seus princípios fundamentais, vantagens e como difere do Separador de Proponente-Construtor Tradicional (PBS).

A PBS substitui a necessidade de um papel de retransmissão confiável usando o próprio protocolo Ethereum. Se o Proponente ou Construtor agir maliciosamente, o protocolo Ethereum pode impor penalidades (como confisco), removendo a dependência de confiar em um papel de terceiros. Esta é a grande diferença em relação à PBS, onde a confiança é externa.

Apesar disso, a separação de funções no ePBS ainda segue a estrutura original do PBS, reduzindo o controle de uma única entidade sobre o conteúdo do bloco, aumentando assim a resistência à censura e a descentralização da rede blockchain.

• Proponente: Responsável por propor o bloco, incluindo informações do cabeçalho do bloco.
• Construtor: Responsável por construir o conteúdo do bloco.

Dois Grandes Benefícios

Punição Direta por Ações Maliciosas & Sem Necessidade de Confiança de Terceiros

Pelo nome, fica claro que o termo "Enshrined" no ePBS reflete seu design integrado ao protocolo, permitindo punição direta para comportamento malicioso. Essa integração transforma sutilmente o modelo de confiança dentro do sistema.

1. Capacidade Incorporada para Detecção e Aplicação

   No PBS, a identificação e penalização de ações maliciosas depende de intervenção de terceiros, como validadores ou relés. Em contraste, o ePBS, sendo nativo do protocolo, permite que o próprio protocolo detecte e trate diretamente a má conduta sem exigir envolvimento externo.

2. Redução da Dependência de Terceiros, Aumentando a Descentralização

   A PBS depende intrinsecamente de governança externa ou terceiros, o que introduz um elemento de centralização da confiança. No entanto, a ePBS incorpora regras dentro do protocolo, reduzindo fundamentalmente a dependência de confiança externa. Essa mudança aumenta a descentralização do sistema, tornando-o mais robusto e resistente à manipulação.

*Comparação entre PBS Tradicional e ePBS👇

Design ePBS

A Dança da Execução e da Verificação

No sistema de Prova de Participação (PoS) do Ethereum, o tempo de cada slot é dividido em intervalos de 12 segundos. Em cada slot, um validador é escolhido aleatoriamente para propor um bloco e um comitê é designado para verificar a validade do bloco. Se um bloco não for proposto durante o slot dado, o validador responsável verificará o bloco anterior após 4 segundos.

Fonte: ethresearch, um slot ePBS será processado pela Camada de Consenso (CL) e Camada de Execução (EL). As informações do bloco são transmitidas na camada de consenso e, em seguida, o bloco é enviado para a camada de execução para verificação.

1. Fase de licitação de blocos: O construtor começa a licitar e envia a licitação ao proponente.
2. Transmissão do Proponente: O Proponente seleciona a oferta vencedora e decide se utilizará a Lista de Inclusão para construir o conteúdo do bloco, em seguida, transmite o bloco.
3. Votação do Validador: Ao ver o bloco, os validadores votam com base nos seus resultados de verificação.
4. Attestação Agregada: As atestações agregadas são criadas pelos Agregadores, que combinam as provas de vários validadores para o mesmo bloco. Os validadores então usam a atestação agregada para verificar o bloco.
5. Transmissão de Carga: O Construtor deve publicar a carga de execução completa dentro do tempo designado.
6. Votação PTC: O Comitê de Pontualidade da Carga (PTC) supervisiona e verifica se a carga do Construtor é pontual e válida.
7. O Proponente do próximo slot publica seu bloco, construindo-o com base nos resultados da votação do PTC e nas atestações agregadas, seja em um bloco cheio ou vazio. Um bloco com uma porcentagem maior de votos PT oportunos é considerado um bloco cheio.

PTC - Garantindo a Pontualidade e Validade das Transações em Novos Blocos \O Comitê de Pontualidade de Carga (PTC) garante que as transações nos novos blocos sejam adicionadas de forma precisa e pontual. Este comitê é composto por validadores (521 membros emprestados do comitê da cadeia de faróis), que verificam se o Construtor concluiu o preenchimento de transações do bloco e se essas transações foram executadas corretamente de acordo com as regras antes do final de cada ciclo de criação de bloco.

Em termos simples, o PTC age como uma equipe supervisora, garantindo que o Construtor envie seu trabalho a tempo e inclua as transações corretas no bloco. Se o Construtor fizer bem e enviar o bloco necessário a tempo, o PTC o confirma por meio de votação. Dessa forma, a rede pode identificar quais blocos estão completos e válidos e quais podem ter problemas ou estarem incompletos.

Através do mecanismo de votação, o PTC influencia se um bloco é considerado um "bloco completo" ou um "bloco vazio". Se o PTC verificar a pontualidade e a correção da carga útil, o bloco será reconhecido como um "bloco completo". Se não houver carga útil ou se a carga estiver atrasada, o bloco pode ser marcado como um "bloco vazio". Com base no voto do PTC, a rede recompensa ou pune diretamente o Proponente e o Construtor para incentivar a construção de blocos oportuna e precisa.

• Bloco Completo: O bloco contém um conjunto completo de carga útil válida, potencialmente incluindo múltiplas transações, e o estado de execução da transação é atualizado de forma oportuna.
• Bloco vazio: O bloco contém muito poucas ou nenhumas transações. Pode ser um bloco CL, mas não atualiza o estado EL.
• Bloco em Falta: Um espaço está vazio. Isso se refere a um bloco que era esperado, mas não foi criado ou adicionado com sucesso à cadeia. Blocos em falta podem ser classificados como cheios ou vazios com base na votação de escolha de garfo (bloco, espaço).

A resistência à censura do ePBS, combinada com o design da lista de inclusão

Embora o design central do ePBS gire em torno da segurança do Builder e conceda aos Builders controle total sobre as transações de blocos, a implementação da Lista de Inclusão torna uma combinação perfeita para alcançar resistência à censura e descentralização.

Nos nossos artigos anteriores, discutimos o CL processo (para mais detalhes, visite: https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg). Em resumo, o Proposer fornece ao Builder uma lista de transações que devem ser priorizadas. Essa lista deve incluir todas as transações atualmente ativas, independentemente de estarem na pool de transações. Desde que haja espaço disponível no bloco, as transações da lista devem ser incluídas no bloco do Builder. Se o bloco estiver cheio, o Builder deve indicar claramente e confirmar que eles reconheceram a lista.

Quando um Construtor tenta censurar certas transações, a taxa base aumentará rapidamente devido à implementação do EIP-1559, já que os blocos são preenchidos continuamente com transações. Se o Construtor insistir em adicionar transações falsas ao bloco para realizar a censura, as taxas crescentes tornarão tais ações proibitivas e impraticáveis.

Resumo

O ePBS separa as funções de Proposer e Builder através da sua integração de protocolo. Com o PTC atuando como um subconjunto do comitê de verificação, é responsável por votar sobre a validade e pontualidade do Execução Payload liberado pelo Builder. A vantagem principal do ePBS está na sua mudança de depender de terceiros confiáveis para ser supervisionado e penalizado diretamente pelo próprio protocolo Ethereum, reduzindo a necessidade de confiar em uma única entidade. Isso não apenas melhora a resistência à censura do sistema, mas também fortalece a proteção das transações através de mecanismos como a Lista de Inclusão, tornando o custo de censurar transações proibitivamente alto e impraticável.

É importante notar que o ePBS fornece uma opção de separação entre Proposers e Builders a nível de protocolo, em vez de ser obrigatório. A diferença fundamental entre o ePBS e outros modelos está nos seus mecanismos de pagamento e modelos de confiança. Ao considerar as questões de confiança de todo o protocolo, o custo a pagar é a necessidade de comprometer-se a pagar taxas antecipadamente. Em contraste, o MEV-Boost permite pagamentos ao Beacon Proposer com base nos lucros obtidos a partir do Execution Payload sequenciado, oferecendo mais margem para a rentabilidade. Talvez um dia, o ePBS possa evoluir para um ponto em que compromissos de taxas antecipadas já não sejam necessários - esta é uma pequena esperança para o futuro!

Referência

@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

Aviso legal：

1. Este artigo é reproduzido a partir de [Uncommons], Todos os direitos autorais pertencem ao autor original [Jocelyn]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizagem da gate. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.