Como é o desempenho do BSC após a implementação completa do PBS?

A BNB Smart Chain (BSC) implementou o BEP-322, o mecanismo de Separação Propositor-Construtor (PBS), no início de 2024. Esta atualização fundamental deu origem ao mercado de Builders da BSC e introduziu novas dinâmicas no ecossistema. Como uma empresa líder em segurança de blockchain, a BlockSec monitora continuamente o desenvolvimento da BSC, analisando potenciais riscos derivados por meio do estudo do mecanismo PBS e de seu ecossistema em evolução. Nosso objetivo é fornecer recomendações robustas de mitigação de riscos para aprimorar a segurança da BSC.

O Cenário em Evolução dos Validadores e Builders da BSC

Os validadores da BSC têm uma influência significativa dentro do ecossistema da BSC. O limite de entrada para os validadores da BSC é notavelmente alto, com seu número consistentemente mantido em torno de 40 a 50. Em comparação com os milhões de nós validadores do Ethereum, os validadores da BSC exercem uma influência mais forte sobre o ecossistema on-chain devido ao seu poder concentrado.

Após meses de intensa competição, o mercado de Builders da BSC formou uma estrutura estável. Players líderes como Blockrazor e 48Club-pussaint agora contribuem com quase 80% da construção de blocos, enquanto Bloxroute, Blocksmith e Nodereal respondem coletivamente por aproximadamente 19%. Os players de cauda contribuem apenas esporadicamente. A análise da BlockSec também destacou o fenômeno de integração vertical entre Validadores e Builders na cadeia BSC, o que pode agravar ainda mais os riscos de centralização e impactar a segurança geral da BNB Smart Chain.

O novo mecanismo também introduziu riscos de transações on-chain, levando ao surgimento de produtos de prevenção de riscos. O mecanismo único de transação 0 Gwei da BSC reduz os custos de transação, mas infelizmente resultou em frequentes atividades de phishing. Sob o mecanismo PBS, o processo do Builder de receber pacotes de transações reduziu o custo dos ataques sanduíche, tornando as transações mais suscetíveis a tais ataques. Isso, por sua vez, impulsionou o desenvolvimento de produtos de RPC privado com o objetivo de mitigar o Valor Máximo Extraível (MEV) e fortalecer a segurança da BSC.

Principais Diferenças Entre as Implementações PBS da BSC e do Ethereum

Um bom ponto de comparação para o mecanismo PBS da BSC é o Ethereum. Embora a BSC tenha adotado a maioria dos princípios de implementação do Ethereum, ainda existem diferenças detalhadas, particularmente nos mecanismos de consenso e na topologia da rede de validadores. Compreender essas distinções é crucial para entender as características únicas de desempenho da BNB Smart Chain após o PBS.

Eliminação do Mecanismo de Relay

Dado o número relativamente pequeno de validadores na BSC, não há necessidade de um Relay centralizado para reduzir a complexidade de comunicação entre Builders e Validadores. Além disso, os intervalos de bloco mais curtos da BSC significam que usar um Relay para encaminhar transações aumentaria os links de comunicação e estenderia o tempo de interação.

Como complemento ao Relay, a BSC introduziu o serviço mev-sentry, onde cada validador opera seu próprio sentry. Este serviço de sentry interage diretamente com os Builders, e sua separação do Validador oferece proteção aprimorada. Ao contrário de um Relay, os Validadores podem obter diretamente o conteúdo do bloco a partir dos lances dos Builders por meio do sentry, permitindo-lhes verificar independentemente a validade dos lances dos Builders. Isso protege ainda mais os interesses dos Validadores. Durante cada intervalo de bloco, os Builders têm permissão para enviar no máximo três lances ao sentry, levando a diferenças significativas nas estratégias de lances entre os Builders da BSC e os Builders do Ethereum.

Diferenças nas Configurações de Transferência de Coinbase

No mecanismo PBS do Ethereum, os Builders têm permissão para alterar o endereço coinbase para o seu próprio, permitindo que as taxas de prioridade do Ethereum sejam executadas e redistribuídas pelos Builders. No entanto, o mecanismo PBS da BSC não possui essa capacidade, o que limita de certa forma a flexibilidade de lances e alocação dos Builders.

Suporte para Transações 0 Gwei

Antes da atualização BEP-322, o mecanismo de transação 0 Gwei foi inicialmente introduzido pelo 48Club como um recurso de associação, oferecido como um serviço especial pelos Validadores aos detentores do token KOGE.

Após a atualização BEP-322, todos os Validadores da BSC foram autorizados a aceitar blocos contendo transações 0 Gwei. Ao contrário do mecanismo dinâmico de Taxa Base do Ethereum, a Taxa Base de transação da BSC é definida como 0 por padrão, o que significa que transações com um Gas Price de 0 são permitidas. Para complementar isso como uma salvaguarda de Gas Fee mínimo, a BSC estabeleceu uma restrição de que o Preço de Gas Efetivo de um bloco não pode cair abaixo de 1. Este mecanismo único permite que os Builders incluam transações 0 Gwei ao construir blocos, possibilitando uma utilização mais eficiente do espaço de bloco e impactando a segurança da BSC.

Desenvolvimento do Mercado de Builders da BSC

Similar ao Ethereum, após a implementação do PBS, o mercado de Builders da BSC emergiu e passou por um período de rápido desenvolvimento, eventualmente formando uma estrutura estável.

De acordo com as estatísticas fornecidas pelo Dune, um total de 8 players Builders participaram do mercado de Builders da BSC. Nos estágios iniciais da implementação do PBS, Nodereal, Blocksmith e Blockrazor dominaram brevemente todo o mercado. No entanto, com 48Club e Bloxroute ingressando na competição no final de junho, o mercado entrou em uma fase de cabo de guerra.

Atualmente, Blockrazor e 48Club respondem por mais de 80% da construção de blocos na BSC, estabelecendo-se como os players líderes no mercado de Builders. Enquanto isso, Bloxroute, Blocksmith e Nodereal tornaram-se players de 'segundo nível', enquanto Jetbldr, Blockbus e Darwin contribuem apenas esporadicamente para a produção de blocos. Essa consolidação influencia significativamente o desempenho da BSC após o PBS.

Desenvolvimento dos Validadores da BSC

Ao contrário do Ethereum, o número de validadores na BSC permanece dentro de uma faixa estável devido às diferenças nos limites de entrada. No Ethereum, qualquer pessoa pode se tornar um validador fazendo staking de 32 ETH, resultando no número de validadores ultrapassando 1 milhão. Os validadores do Ethereum se integram com Relays para se conectar com Builders, receber propostas de blocos e concluir a produção de blocos.

Na BSC, no entanto, tornar-se um validador requer o staking de uma grande quantidade de BNB, elevando significativamente a barreira de entrada. Atualmente, existem apenas 45 validadores na BSC, com 21 classificados como Cabinet e os 24 restantes como Candidates. De acordo com as estatísticas do BSCScan, esses 45 validadores fizeram staking coletivo de 29.244.219 BNB (em 18 de dezembro de 2024), com o validador que fez o menor staking ainda detendo 73.446 BNB.

Essa diferença na concentração de validadores levou, em certa medida, a diferenças ecológicas entre a BSC e o Ethereum. Por exemplo, na BSC, o menor custo de vinculação entre Builders e Validadores elimina o espaço de mercado para os serviços de Relay. Ao mesmo tempo, a alta influência dos validadores significa que o desenvolvimento do ecossistema on-chain deve priorizar os interesses dos validadores. Isso pode afetar a competitividade e o entusiasmo de outras equipes de projeto dentro do ecossistema colaborativo da cadeia pública, além dos grupos de validadores, representando um desafio para a segurança da BNB Smart Chain a longo prazo.

Potenciais Riscos On-Chain Após a Implementação do PBS

A implementação completa do PBS na BSC, embora traga melhorias arquitetônicas, também revelou vários riscos potenciais que exigem atenção, particularmente em relação à segurança da BSC.

Integração Vertical Builder-Validador

Existe um fenômeno significativo de integração vertical Builder-Validador na BSC. A BlockSec analisou a distribuição de blocos produzidos por Builders em todos os Validadores de 1º de dezembro, 00:00:00 (UTC) a 18 de dezembro, 00:00:00 (UTC). Os dados mostram que alguns nós validadores têm estatísticas de produção de blocos que desviam significativamente da média do mercado, indicando a existência de integração vertical.

Por exemplo:

• Nodereal tem uma participação de 100% com TWStaking.
• Bloxroute tem uma participação de 100% com Figment.
• 48Club detém mais de 90% de participação com Turing, The48Club, Shannon, Lista, Feynman e Avengers.

Os riscos potenciais decorrentes dessa integração vertical diferem da integração Searcher-Builder mais comum vista no Ethereum. Especificamente, o mecanismo de integração Builder-Validador pode ser explorado para controlar o fluxo de transações, transmitindo transações apenas para Validadores específicos. Isso poderia resultar em perdas para os interesses dos usuários e agravar os riscos de centralização, impactando diretamente a segurança da BNB Smart Chain.

Riscos do Mecanismo de Transação 0 Gwei

O mecanismo de transação 0 Gwei, embora reduza custos, cria oportunidades de exploração por contratos de phishing. Com transações 0 Gwei, contratos de phishing podem transferir fundos sem custo algum, agravando a prevalência de ataques de phishing.

Na BSC, a BlockSec já detectou múltiplos contratos de phishing utilizando transações 0 Gwei. Inicialmente, esses contratos aproveitaram o serviço de transação 0 Gwei do 48Club ao deter Koge. Embora o 48Club tenha implementado certas restrições, no momento da redação deste artigo, ainda observamos várias atividades de phishing sendo realizadas por meio do serviço de transação 0 Gwei do 48Club, representando uma ameaça significativa à segurança da BSC.

Ataques MEV Estão se Tornando Mais Desenfreados, Especialmente Ataques Sanduíche

O atual mecanismo PBS da BSC embaralhou o mercado de ataques MEV, tornando essencial para os usuários compreenderem as estratégias de proteção contra MEV nessa nova estrutura. Entre os vários ataques MEV, o ataque sanduíche é um dos mais notórios no blockchain.

Como Funciona um Ataque Sanduíche:

1. Monitoramento da Transação Alvo: O atacante monitora o pool de transações do blockchain (mempool) para identificar transações alvo. Esses alvos são tipicamente grandes transações de troca de tokens (por exemplo, trocar ETH por USDT em uma DEX).
2. Execução Antecipada da Transação Alvo: O atacante envia uma transação antes da transação alvo (front-running) para influenciar o preço de mercado. Por exemplo, o atacante compra o token alvo, elevando seu preço.
3. Execução Posterior à Transação Alvo: Após a execução da transação alvo, o atacante envia outra transação depois dela (back-running) para vender os tokens adquiridos na etapa de front-running. Isso permite que o atacante lucre com as flutuações de preço causadas pela transação alvo.

Para mais informações sobre MEV, leia nossa análise detalhada: Colhendo Bots MEV ao Explorar Vulnerabilidades no Relay do Flashbots.

Antes da implementação do PBS, as transações eram totalmente expostas no pool de transações público, tornando-as visíveis para os atacantes. Os atacantes podiam analisar todas as transações lucrativas e manipular a ordem das transações controlando o preço do gas, permitindo-lhes realizar ataques.

O mecanismo PBS da BSC introduz um canal privado para transações, permitindo que os usuários enviem suas transações para um pool de transações privado que é visível apenas para os Builders. Isso garante que as transações permaneçam ocultas dos atacantes (a menos que um Builder as vaze deliberadamente), fornecendo uma camada de proteção contra MEV para as transações dos usuários.

Observamos que um bot sanduíche líder (0x00000000004e660d7929B04626BbF28CBECCe534), que anteriormente realizava ataques sanduíche controlando os preços do gas, cessou completamente suas operações há mais de 100 dias. Isso indica que o mecanismo PBS na BSC reorganizou o cenário de ataques MEV.

No entanto, ao observar o comportamento on-chain e analisar dados estatísticos (por exemplo, Dune Analytics), descobrimos que após a implementação do PBS (maio de 2024), o número de transações de ataque sanduíche na cadeia BSC aumentou significativamente. Esse paradoxo destaca uma lacuna crítica nas atuais estratégias de proteção contra MEV na BSC.

A principal razão para o aumento dos ataques sanduíche é que a maioria dos traders e equipes de projeto não utilizou efetivamente os canais privados fornecidos pelo PBS. Em vez disso, continuam enviando transações para o pool de transações público. Para os atacantes, o custo de obtenção de oportunidades de ataque não aumentou significativamente.

Pelo contrário, os atacantes exploram a capacidade do Builder de aceitar pacotes, empacotando tanto a transação alvo quanto a transação de ataque em um único pacote enviado ao Builder. Se o pacote for incluído com sucesso on-chain, o ataque sanduíche é bem-sucedido. Se falhar, o Searcher não incorre em nenhuma perda. Isso torna os ataques sanduíche mais econômicos e eficientes, enfatizando ainda mais a necessidade de uma proteção contra MEV robusta.