TL;DR

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

Introdução

Em fevereiro, o desenvolvedor Potuz da Prysm levantou preocupações sobre problemas 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 relés confiáveis. Os relés armazenam o conteúdo do bloco e garantem que o Proponente receba o conteúdo do bloco, mas não consiga roubar facilmente o conteúdo do Construtor. No entanto, se o relé for malicioso, tanto o Proponente quanto o Construtor podem ser prejudicados e só podem mudar para outro relé e esperar que não seja malicioso. Isso apresenta um problema: devemos encontrar uma terceira parte confiável para delegaçã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 de bloco.
• Os construtores devem confiar no intermediário se quiserem comprar os direitos de construção de blocos.

Design Revolucionário do ePBS

Separação Incorporada entre Proposer-Builder

Enshrined Proposer-Builder Separation (ePBS) é uma variante do PBS integrada diretamente na camada de consenso do Ethereum, também conhecida como In-Protocol PBS. Foi projetada para lidar com possíveis falhas de retransmissão e eliminar os pontos únicos de falha do sistema. Como um mecanismo de consenso emergente, agora vamos aprofundar o ePBS, explicando seus princípios básicos, vantagens e como ele difere do tradicional Proposer-Builder Separation (PBS).

PBS substitui a necessidade de um papel de relé confiável usando o próprio protocolo Ethereum. Se o Proponente ou Construtor agir de forma maliciosa, o protocolo Ethereum pode impor penalidades (como confisco), removendo a dependência de confiar em um papel de terceiros. Esta é a principal diferença do 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, assim aumentando 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.
• Builder: Responsável por construir o conteúdo do bloco.

Dois Principais Benefícios

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

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

1. Capacidade Incorporada para Detecção e Cumprimento

   No PBS, identificar e penalizar ações maliciosas depende da intervenção de terceiros, como validadores ou relés. Em contraste, o ePBS, sendo protocolo nativo, permite que o próprio protocolo detecte e lide diretamente com condutas indevidas sem exigir envolvimento externo.

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

   A PBS depende intrinsecamente de governança externa ou terceiros, o que introduz um elemento de centralização de confiança. O ePBS, no entanto, 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 o Traditional PBS e o ePBS👇

Design do ePBS

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

No sistema de Proof of Stake (PoS) do Ethereum, o tempo para cada intervalo é dividido em intervalos de 12 segundos. Em cada intervalo, 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 intervalo previsto, 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 de bloco são transmitidas na camada de consenso e, em seguida, o bloco é submetido à camada de execução para verificação.

1. Fase de licitação por bloco: O Construtor começa a licitar e envia a oferta ao Proponente.
2. Transmissão do Proponente: O Proponente seleciona a oferta vencedora e decide se usará 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 em seus resultados de verificação.
4. Attestação Agregada: As Attestaçõ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 Payload: O construtor deve publicar o payload de execução completo 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 Proposer da próxima slot publica seu bloco, construindo-o com base nos resultados de votação do PTC e nas atestações agregadas, em um bloco cheio ou vazio. Um bloco com uma porcentagem mais alta de votos do PTC pontuais é considerado um bloco cheio.

PTC - Garantia de Tempestividade e Validade das Transações em Novos Blocos \O Comitê de Pontualidade da Carga (PTC) garante que as transações nos novos blocos sejam adicionadas de forma rápida e precisa. Este comitê é composto por validadores (521 membros emprestados do comitê da cadeia farol), que verificam se o Construtor concluiu o preenchimento das transações do bloco e se essas transações são 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 de supervisão, garantindo que o Construtor envie seu trabalho no prazo e inclua as transações corretas no bloco. Se o Construtor se sair bem e enviar o bloco necessário no prazo, 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 estar incompletos.

Através do mecanismo de votação, o PTC influencia se um bloco é considerado um “bloco cheio” ou um “bloco vazio”. Se o PTC verifica a pontualidade e correção da carga útil, o bloco é reconhecido como um “bloco cheio”. Se não houver carga útil ou a carga útil 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 pontuais e precisos.

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

Resistência à censura da ePBS, combinada com o design da lista de inclusão

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

Em nossos artigos anteriores, discutimos o CLprocesso (para mais detalhes, visite:https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rgEm resumo, o Proponente fornece ao Construtor uma lista de transações que devem ser priorizadas. Esta lista deve incluir todas as transações atualmente ativas, independentemente de estarem na pool de transações. Desde que haja espaço restante no bloco, as transações da lista devem ser incluídas no bloco do Construtor. Se o bloco estiver cheio, o Construtor deve indicar claramente e confirmar que reconheceu a lista.

Quando um Construtor tenta censurar certas transações, a taxa base irá aumentar rapidamente devido à implementação do EIP-1559, pois os blocos são continuamente preenchidos 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 os papéis de Proponente e Construtor por meio de sua integração de protocolo. Com o PTC atuando como um subconjunto do comitê de verificação, ele é responsável por votar sobre a validade e pontualidade da Carga de Execução lançada pelo Construtor. A principal vantagem do ePBS está em 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 aprimora a resistência à censura do sistema, mas também fortalece a proteção de transações por meio de mecanismos como a Lista de Inclusão, tornando o custo de censurar transações proibitivamente alto e impraticável.

É importante observar que o ePBS fornece uma opção para a separação do construtor de propostas de bloco no nível do protocolo, em vez de ser obrigatório. A principal distinção entre o ePBS e outros modelos está em seus mecanismos de pagamento e modelos de confiança. Ao considerar as questões de confiança de todo o protocolo, o custo a ser pago é a necessidade de se comprometer a pagar taxas antecipadamente. Em contraste, o MEV-Boost permite pagamentos ao Propositor do Beacon com base nos lucros derivados da Sequência de Carga de Execução, oferecendo mais espaço para lucratividade. Talvez um dia, o ePBS possa evoluir para um ponto em que os compromissos de taxa antecipada não sejam mais 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 [Incomuns], Todos os direitos autorais pertencem ao autor original [Jocelyn]. Se houver objeções a este reenvio, entre em contato com o Gate Aprendaa equipe e eles resolverão isso prontamente.
2. Isenção de responsabilidade de responsabilidade: as opiniões expressas neste artigo são exclusivamente as 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 aprendizado da gate. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.