O núcleo do design da ePBS é construído em torno do conceito de segurança do Builder, concedendo ao Builder total controle sobre as transações do Bloco.
ePBS é uma proposta para incorporar o PBS diretamente na camada de consenso do Ethereum, conhecida como PBS no Protocolo, com o objetivo de lidar com possíveis falhas de relé e eliminar falhas pontuais no sistema.
O ePBS ainda segue a base do PBS original, aumentando a capacidade de resistência à censura e descentralização da rede, através do controle de conteúdo pelo único entidade Gota Bloco.
Comitê de Pontualidade de Carga Útil (PTC) atua como supervisor para garantir a oportunidade e eficácia do conteúdo da transação no novo bloco.
Prefácio
Em fevereiro, o desenvolvedor Prysm Potuz acredita que há um problema de confiança na rede principal do Ethereum, e propõe adiar o fork Electra para 2025, a fim de aprimorar o design do ePBS através do evento Interop. No entanto, a comunidade Ethereum tem opiniões divergentes sobre o ePBS, com alguns desenvolvedores e pesquisadores preocupados com os possíveis riscos envolvidos. As opiniões sobre o ePBS são diferentes, então hoje vamos entender o que é ePBS e qual a diferença em relação ao PBS.
Anteriormente mencionamos que o mecanismo do PBS é para garantir a segurança das promessas do Proposer e a segurança das interpretações do Builder, por isso esse poder é entregue a um Relé confiável. O Relé é responsável por guardar o conteúdo do Bloco, garantindo que o Proposer obtenha o conteúdo do Bloco, mas não consiga facilmente roubar o conteúdo do Bloco do Builder. No entanto, se o Relé for malicioso, tanto o Proposer quanto o Builder serão prejudicados e terão que recorrer a outros Relays e esperar que os outros Relés não sejam maliciosos. Aqui surge um problema, precisamos encontrar um terceiro confiável para delegar a confiança, porque o PBS é uma solução fora do protocolo. O PBS depende do consenso e da conformidade voluntária da comunidade, exigindo coordenação e confiança adicionais.
Na PBS, deve haver um papel de intermediário como terceira parte de crédito para lidar com problemas: 01928374656574839201
Proposer 若想要出售Bloco内容的权利必须信任intermediário。
Builder quer comprar o direito de construir Bloco deve confiar no intermediário.
O design revolucionário do ePBS
Separation of proposers and builders built-in
Separação Enraizada Proposer-Builder (ePBS) é uma variante do PBS. O ePBS é uma proposta que incorpora diretamente o PBS na camada de Consenso do Ethereum, sendo também conhecido como In-Protocol PBS. Sua criação visa lidar com possíveis falhas no Relé e eliminar pontos únicos de falha no sistema. Como um novo mecanismo de consenso, aprofundaremos a análise do ePBS a seguir, com o objetivo de esclarecer seus princípios fundamentais, vantagens e diferenças em relação à Separação Tradicional de Proposer-Builder (PBS).
ePBS, ou seja, Proposer-Builder Separado, é um mecanismo embutido no protocolo de blockchain. Em vez de confiar em um papel de Relay que precisa ser confiável, o Ethereum protocolo pode punir (corte) tanto o Proposer quanto o Builder se um deles agir mal, sem depender da confiança em um determinado papel. Esta é a maior diferença entre o protocolo como um todo e o PBS protocolo que mencionamos anteriormente.
Claro, a separação de funções no uso do ePBS ainda segue a base do PBS original, aumentando o nível de resistência à censura e descentralização da rede Blockchain através da capacidade de controle de conteúdo de um único bloco.
Proposer：Responsável pela proposta de Bloco, incluindo informações do cabeçalho de Bloco
Builder: conteúdo específico para a construção do Bloco
Dois grandes benefícios
Punição direta de más ações e sem a necessidade de terceiros de confiança
Observando o nome, pode-se deduzir que em ePBS, o Enshrined pode ser conhecido por incorporar o protocolo, o que também resultará em punições diretas para o comportamento malicioso e uma mudança silenciosa no centro de confiança sob essa configuração.
O protocolo possui capacidade de reconhecimento e processamento, punindo diretamente
No PBS, a identificação e punição de comportamentos maliciosos dependem da intervenção de terceiros (validadores, retransmissores, etc.). No ePBS, devido ao seu design no próprio protocolo, os comportamentos maliciosos podem ser diretamente identificados e tratados pelo próprio protocolo.
Sem a necessidade de confiar em terceiros, aumenta o nível de descentralização
PBS em certo sentido depende da governança externa ou de terceiros, o que gera problemas de centralização de confiança. Por outro lado, ePBS, ao escrever as regras no protocolo, reduz a necessidade de confiança em terceiros externos desde o início, aumentando o nível de descentralização do sistema.
*Comparação de gráficos tradicionais PBS e ePBS
Design ePBS
A dança da execução e verificação
No POS do Ethereum, o tempo do slot é dividido em intervalos de 12 segundos. Em cada slot, um validador é selecionado aleatoriamente para propor um bloco. Ao mesmo tempo, um comité é designado para validar a validade do bloco. Se um bloco não for proposto num determinado slot, os validadores responsáveis pela prova irão validar o bloco anterior após 4 segundos.
fonte: ethresearch, um slot ePBS será processado pelo CL (camada de consenso) e EL (camada de execução). A informação Bloco é transmitida na camada de consenso, e em seguida o Bloco é submetido à camada de execução para verificação.
proposer Broadcast: O proponente escolhe Licitação e decide se usa a Lista de Inclusão para construir o conteúdo do seu Bloco. Em seguida, ele transmite o Bloco.
Votação dos validadores: após a visualização do Bloco, os validadores votarão com base no resultado da sua validação.
Agregação de atestação: A agregação de atestação é criada por agregadores, que agregam as provas de vários validadores para o mesmo Bloco. Os validadores verificam a agregação de atestação.
carga de transmissão: O Builder precisa divulgar a carga útil de execução completa dentro do tempo especificado.
Votação PTC: Comitê Especial para supervisionar e verificar se a carga útil do Builder está sendo entregue de forma oportuna e eficiente.
O Proposer do próximo slot publica seu Bloco com base nos resultados da votação do PTC e na prova agregada construída no Bloco completo ou no Bloco vazio. Quando a porcentagem de votos do PT em um Bloco publicado em tempo é maior, ele é considerado um Bloco completo.
PTC, supervision of the timely and effective transaction content in the new blockchain
Comitê de Pontualidade da Carga Útil (PTC), 'Comitê de Pontualidade da Carga Útil'. A principal tarefa é garantir que o conteúdo das transações no novo Bloco seja adicionado de forma oportuna e precisa. Este comitê é composto por validadores (um total de 521 pessoas emprestadas do comitê de correntes de farol como parte do comitê), cujo trabalho é verificar se o Builder completou o preenchimento das transações do Bloco antes do final de cada ciclo de criação do Bloco e se essas transações foram executadas corretamente de acordo com as regras.
Em termos simples, o PTC é como uma equipe de supervisão que monitora se o Builder enviou seu trabalho no prazo e se incluiu o Bloco de transações correto. Se o Builder fizer um bom trabalho, enviando o Bloco correto no prazo, o PTC confirmará isso por meio de votação. Dessa forma, a rede pode determinar quais Blocos são completos e válidos e quais podem ter problemas ou estar incompletos.
Através do mecanismo de votação, o PTC influencia se o Bloco é considerado no estado de "Bloco completo" ou "Bloco vazio". Se o PTC verificar a pontualidade e correção da carga, o Bloco pode ser considerado no estado de "Bloco completo"; se não houver carga ou se a carga for submetida à latência, o Bloco pode ser marcado como "Bloco vazio". Em seguida, com base nos resultados da votação do PTC, a rede recompensa ou penaliza diretamente o Proposer e o Builder para incentivar a construção oportuna e precisa do Bloco.
Bloco completo: O bloco contém um conjunto válido de dados, que pode incluir várias transações, e o estado de execução das transações é atualizado em tempo hábil.
Implementação de resistência à censura do ePBS, combinada com o design da Lista de Inclusão
Embora o núcleo do design do ePBS seja construído em torno da segurança do Builder, ele concede ao Builder total controle sobre as transações de Bloco. Assim, com base nisso, o uso da Lista de Inclusão será uma combinação perfeita para alcançar uma forma de resistência à censura e Descentralização.
Anteriormente, em nossos artigos, mencionamos o CL, descrevendo brevemente o processo (para mais detalhes, clique no link: undefined). ** Envie esta lista para o Builder, priorizando essas transações. Deve abranger todas as transações ativas atualmente, independentemente de estarem na mempool. Desde que o Bloco ainda tenha espaço disponível, as transações da lista devem ser incluídas no Bloco do Builder. Se o Bloco estiver cheio, o Builder deve identificá-lo claramente e confirmar que eles estão cientes desta lista.
Quando o Builder tenta rever algumas transações, devido à implementação do EIP-1559, o Bloco que está sendo constantemente preenchido com transações levará a uma rápida Ascensão da taxa base. Se o Builder insistir em adicionar transações falsas ao Bloco para revisão neste momento, os custos crescentes tornarão esse comportamento economicamente inviável e deixarão de ser práticos.
Resumo
O ePBS separa os papéis do proponente e do construtor, incorporados no protocolo. O PTC, como um subconjunto do comitê de prova, é responsável por votar a validade e pontualidade da carga de execução emitida pelo construtor. Sua principal vantagem é transformar o papel tradicional de terceiros de confiança em um papel desempenhado pelo próprio protocolo Ethereum, executando supervisão e punição, reduzindo assim a necessidade de confiar em uma única entidade. Isso não apenas aumenta a resistência à censura do sistema, mas também aprimora a proteção das transações por meio de mecanismos como a Lista de Inclusão, tornando o custo de auditar transações caro e impraticável.
Além disso, deve ser declarado que o ePBS apenas fornece uma opção de separação entre o Bloco Proposer e o Builder no nível do protocolo, em vez de ser obrigatório. A maior diferença entre eles está no mecanismo de pagamento e no modelo de confiança. Ao considerar a questão da confiança em todo o protocolo, o custo é o compromisso antecipado de pagamento. Em comparação com o ePBS, o MEV-Boost pode determinar o valor a pagar ao Beacon Proposer com base nos lucros obtidos na ution Payload ordenada, oferecendo mais lucro e flexibilidade. Talvez um dia, com um pouco de fantasia e expectativa, o mecanismo do ePBS possa ser implementado sem a necessidade de compromisso antecipado de pagamento!
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Experimento Crise de confiança incorporado no protocolo ePBS
TL;DR
Prefácio
Em fevereiro, o desenvolvedor Prysm Potuz acredita que há um problema de confiança na rede principal do Ethereum, e propõe adiar o fork Electra para 2025, a fim de aprimorar o design do ePBS através do evento Interop. No entanto, a comunidade Ethereum tem opiniões divergentes sobre o ePBS, com alguns desenvolvedores e pesquisadores preocupados com os possíveis riscos envolvidos. As opiniões sobre o ePBS são diferentes, então hoje vamos entender o que é ePBS e qual a diferença em relação ao PBS.
Anteriormente mencionamos que o mecanismo do PBS é para garantir a segurança das promessas do Proposer e a segurança das interpretações do Builder, por isso esse poder é entregue a um Relé confiável. O Relé é responsável por guardar o conteúdo do Bloco, garantindo que o Proposer obtenha o conteúdo do Bloco, mas não consiga facilmente roubar o conteúdo do Bloco do Builder. No entanto, se o Relé for malicioso, tanto o Proposer quanto o Builder serão prejudicados e terão que recorrer a outros Relays e esperar que os outros Relés não sejam maliciosos. Aqui surge um problema, precisamos encontrar um terceiro confiável para delegar a confiança, porque o PBS é uma solução fora do protocolo. O PBS depende do consenso e da conformidade voluntária da comunidade, exigindo coordenação e confiança adicionais.
Na PBS, deve haver um papel de intermediário como terceira parte de crédito para lidar com problemas: 01928374656574839201
O design revolucionário do ePBS
Separation of proposers and builders built-in
Separação Enraizada Proposer-Builder (ePBS) é uma variante do PBS. O ePBS é uma proposta que incorpora diretamente o PBS na camada de Consenso do Ethereum, sendo também conhecido como In-Protocol PBS. Sua criação visa lidar com possíveis falhas no Relé e eliminar pontos únicos de falha no sistema. Como um novo mecanismo de consenso, aprofundaremos a análise do ePBS a seguir, com o objetivo de esclarecer seus princípios fundamentais, vantagens e diferenças em relação à Separação Tradicional de Proposer-Builder (PBS).
ePBS, ou seja, Proposer-Builder Separado, é um mecanismo embutido no protocolo de blockchain. Em vez de confiar em um papel de Relay que precisa ser confiável, o Ethereum protocolo pode punir (corte) tanto o Proposer quanto o Builder se um deles agir mal, sem depender da confiança em um determinado papel. Esta é a maior diferença entre o protocolo como um todo e o PBS protocolo que mencionamos anteriormente.
Claro, a separação de funções no uso do ePBS ainda segue a base do PBS original, aumentando o nível de resistência à censura e descentralização da rede Blockchain através da capacidade de controle de conteúdo de um único bloco.
Dois grandes benefícios
Punição direta de más ações e sem a necessidade de terceiros de confiança
Observando o nome, pode-se deduzir que em ePBS, o Enshrined pode ser conhecido por incorporar o protocolo, o que também resultará em punições diretas para o comportamento malicioso e uma mudança silenciosa no centro de confiança sob essa configuração.
No PBS, a identificação e punição de comportamentos maliciosos dependem da intervenção de terceiros (validadores, retransmissores, etc.). No ePBS, devido ao seu design no próprio protocolo, os comportamentos maliciosos podem ser diretamente identificados e tratados pelo próprio protocolo.
PBS em certo sentido depende da governança externa ou de terceiros, o que gera problemas de centralização de confiança. Por outro lado, ePBS, ao escrever as regras no protocolo, reduz a necessidade de confiança em terceiros externos desde o início, aumentando o nível de descentralização do sistema.
*Comparação de gráficos tradicionais PBS e ePBS
Design ePBS
A dança da execução e verificação
No POS do Ethereum, o tempo do slot é dividido em intervalos de 12 segundos. Em cada slot, um validador é selecionado aleatoriamente para propor um bloco. Ao mesmo tempo, um comité é designado para validar a validade do bloco. Se um bloco não for proposto num determinado slot, os validadores responsáveis pela prova irão validar o bloco anterior após 4 segundos.
fonte: ethresearch, um slot ePBS será processado pelo CL (camada de consenso) e EL (camada de execução). A informação Bloco é transmitida na camada de consenso, e em seguida o Bloco é submetido à camada de execução para verificação.
PTC, supervision of the timely and effective transaction content in the new blockchain
Comitê de Pontualidade da Carga Útil (PTC), 'Comitê de Pontualidade da Carga Útil'. A principal tarefa é garantir que o conteúdo das transações no novo Bloco seja adicionado de forma oportuna e precisa. Este comitê é composto por validadores (um total de 521 pessoas emprestadas do comitê de correntes de farol como parte do comitê), cujo trabalho é verificar se o Builder completou o preenchimento das transações do Bloco antes do final de cada ciclo de criação do Bloco e se essas transações foram executadas corretamente de acordo com as regras.
Em termos simples, o PTC é como uma equipe de supervisão que monitora se o Builder enviou seu trabalho no prazo e se incluiu o Bloco de transações correto. Se o Builder fizer um bom trabalho, enviando o Bloco correto no prazo, o PTC confirmará isso por meio de votação. Dessa forma, a rede pode determinar quais Blocos são completos e válidos e quais podem ter problemas ou estar incompletos.
Através do mecanismo de votação, o PTC influencia se o Bloco é considerado no estado de "Bloco completo" ou "Bloco vazio". Se o PTC verificar a pontualidade e correção da carga, o Bloco pode ser considerado no estado de "Bloco completo"; se não houver carga ou se a carga for submetida à latência, o Bloco pode ser marcado como "Bloco vazio". Em seguida, com base nos resultados da votação do PTC, a rede recompensa ou penaliza diretamente o Proposer e o Builder para incentivar a construção oportuna e precisa do Bloco.
Implementação de resistência à censura do ePBS, combinada com o design da Lista de Inclusão
Embora o núcleo do design do ePBS seja construído em torno da segurança do Builder, ele concede ao Builder total controle sobre as transações de Bloco. Assim, com base nisso, o uso da Lista de Inclusão será uma combinação perfeita para alcançar uma forma de resistência à censura e Descentralização.
Anteriormente, em nossos artigos, mencionamos o CL, descrevendo brevemente o processo (para mais detalhes, clique no link: undefined). ** Envie esta lista para o Builder, priorizando essas transações. Deve abranger todas as transações ativas atualmente, independentemente de estarem na mempool. Desde que o Bloco ainda tenha espaço disponível, as transações da lista devem ser incluídas no Bloco do Builder. Se o Bloco estiver cheio, o Builder deve identificá-lo claramente e confirmar que eles estão cientes desta lista.
Quando o Builder tenta rever algumas transações, devido à implementação do EIP-1559, o Bloco que está sendo constantemente preenchido com transações levará a uma rápida Ascensão da taxa base. Se o Builder insistir em adicionar transações falsas ao Bloco para revisão neste momento, os custos crescentes tornarão esse comportamento economicamente inviável e deixarão de ser práticos.
Resumo
O ePBS separa os papéis do proponente e do construtor, incorporados no protocolo. O PTC, como um subconjunto do comitê de prova, é responsável por votar a validade e pontualidade da carga de execução emitida pelo construtor. Sua principal vantagem é transformar o papel tradicional de terceiros de confiança em um papel desempenhado pelo próprio protocolo Ethereum, executando supervisão e punição, reduzindo assim a necessidade de confiar em uma única entidade. Isso não apenas aumenta a resistência à censura do sistema, mas também aprimora a proteção das transações por meio de mecanismos como a Lista de Inclusão, tornando o custo de auditar transações caro e impraticável.
Além disso, deve ser declarado que o ePBS apenas fornece uma opção de separação entre o Bloco Proposer e o Builder no nível do protocolo, em vez de ser obrigatório. A maior diferença entre eles está no mecanismo de pagamento e no modelo de confiança. Ao considerar a questão da confiança em todo o protocolo, o custo é o compromisso antecipado de pagamento. Em comparação com o ePBS, o MEV-Boost pode determinar o valor a pagar ao Beacon Proposer com base nos lucros obtidos na ution Payload ordenada, oferecendo mais lucro e flexibilidade. Talvez um dia, com um pouco de fantasia e expectativa, o mecanismo do ePBS possa ser implementado sem a necessidade de compromisso antecipado de pagamento!