BNB Smart Chain (BSC) implementou o BEP-322, o mecanismo de Proposer-Builder Separation (PBS), no início de 2024. Essa atualização crucial deu origem ao mercado de Builders da BSC e introduziu novas dinâmicas ao ecossistema. Como uma empresa líder em segurança blockchain, a BlockSec monitora continuamente o desenvolvimento da BSC, analisando possíveis riscos derivados por meio do estudo do mecanismo PBS e da evolução de seu ecossistema. Nosso objetivo é fornecer recomendações robustas de mitigação de risco para fortalecer a segurança da BSC.
O Cenário em Evolução dos Validadores e Builders da BSC
Os validadores da BSC exercem influência significativa dentro do ecossistema da BSC. O limite de entrada para validadores da BSC é notavelmente alto, com o número mantido consistentemente entre 40 e 50. Em comparação com os milhões de nós validadores da Ethereum, os validadores da BSC exercem uma influência mais forte sobre o ecossistema on-chain devido à sua concentração de poder.
Após meses de intensa competição, o mercado de Builders da BSC formou uma estrutura estável. Players de destaque como Blockrazor e 48Club-pussaint contribuem hoje com quase 80% da construção de blocos, enquanto Bloxroute, Blocksmith e Nodereal representam coletivamente aproximadamente 19%. Os players de menor porte contribuem apenas esporadicamente. A análise da BlockSec também destacou o fenômeno de integração vertical entre Validators 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 nas transações on-chain, levando ao surgimento de produtos de prevenção de risco. O mecanismo exclusivo de transações de 0 Gwei da BSC reduz os custos de transação, mas infelizmente resultou em atividades frequentes de phishing. Sob o mecanismo PBS, o processo de recebimento de pacotes de transações pelo Builder reduziu o custo dos ataques sandwich, tornando as transações mais suscetíveis a esse tipo de ataque. Isso, por sua vez, impulsionou o desenvolvimento de produtos de RPC privado voltados a mitigar o Maximum Extractable Value (MEV) e a reforçar a segurança da BSC.
Principais Diferenças Entre as Implementações de PBS da BSC e da Ethereum
Um bom ponto de comparação para o mecanismo PBS da BSC é a Ethereum. Embora a BSC tenha adotado a maioria dos princípios de implementação da Ethereum, ainda existem diferenças detalhadas, particularmente nos mecanismos de consenso e na topologia da rede de validadores. Compreender essas distinções é fundamental para entender as características de desempenho exclusivas 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 Validators. Além disso, os intervalos de blocos mais curtos da BSC significam que o uso de um Relay para retransmitir transações na verdade aumentaria os links de comunicação e prolongaria o tempo de interação.
Como complemento ao Relay, a BSC introduziu o serviço mev-sentry, no qual cada validador opera seu próprio sentry. Esse serviço de sentry interage diretamente com os Builders, e sua separação do Validator proporciona proteção reforçada. Diferente de um Relay, os Validators podem obter diretamente o conteúdo do bloco a partir dos lances dos Builders por meio do sentry, permitindo que verifiquem de forma independente a validade dos lances dos Builders. Isso protege ainda mais os interesses dos Validators. Durante cada intervalo de bloco, os Builders podem enviar no máximo três lances ao sentry, o que gera diferenças significativas nas estratégias de lance entre os Builders da BSC e os Builders da Ethereum.
Diferenças nas Configurações de Transferência do Coinbase
No mecanismo PBS da Ethereum, os Builders podem alterar o endereço coinbase para o próprio endereço, permitindo que as taxas de prioridade da 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 a Transações de 0 Gwei
Antes da atualização BEP-322, o mecanismo de transação de 0 Gwei foi inicialmente introduzido pela 48Club como um recurso de membresia, oferecido como um serviço especial pelos Validators aos detentores do token KOGE.
Após a atualização BEP-322, todos os Validators da BSC foram autorizados a aceitar blocos contendo transações de 0 Gwei. Diferente do mecanismo dinâmico de Base Fee da Ethereum, a Base Fee de transação da BSC é definida como 0 por padrão, o que significa que transações com Gas Price igual a 0 são permitidas. Como salvaguarda complementar de taxa mínima de Gas, a BSC estabeleceu uma restrição de que o Effective Gas Price de um bloco não pode ficar abaixo de 1. Esse mecanismo exclusivo permite que os Builders incluam transações de 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
Semelhante à Ethereum, após a implementação do PBS, o mercado de Builders da BSC surgiu e passou por um período de rápido desenvolvimento, formando eventualmente uma estrutura estável.
De acordo com estatísticas fornecidas pela Dune, um total de 8 players Builder 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 a entrada da 48Club e da Bloxroute na competição no final de junho, o mercado entrou em uma fase de disputa acirrada.
Atualmente, Blockrazor e 48Club representam mais de 80% da construção de blocos na BSC, consolidando-se como os principais players do mercado de Builders. Enquanto isso, Bloxroute, Blocksmith e Nodereal se tornaram 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
Diferente da Ethereum, o número de validadores na BSC permanece dentro de uma faixa estável devido às diferenças nos limites de entrada. Na Ethereum, qualquer pessoa pode se tornar um validador ao fazer staking de 32 ETH, o que resultou em um número de validadores superior a 1 milhão. Os validadores da Ethereum se integram com Relays para se conectar com Builders, receber propostas de blocos e concluir a produção de blocos.
Na BSC, porém, 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 demais 24 como Candidates. De acordo com estatísticas da BSCScan, esses 45 validadores fizeram staking coletivo de 29.244.219 BNB (até 18 de dezembro de 2024), sendo que o validador com o menor volume em staking ainda detém 73.446 BNB.
Essa diferença na concentração de validadores levou, até certo ponto, a diferenças ecológicas entre a BSC e a Ethereum. Por exemplo, na BSC, o menor custo para conectar Builders e Validators elimina o espaço de mercado para 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 blockchain pública, além dos grupos de validadores, representando um desafio para a segurança da BNB Smart Chain no longo prazo.
Riscos Potenciais On-Chain Após a Implementação do PBS
A implementação total do PBS na BSC, embora tenha trazido melhorias arquitetônicas, também revelou diversos riscos potenciais que exigem atenção, particularmente no que se refere à segurança da BSC.
Integração Vertical Entre Builder e Validator
Há um fenômeno significativo de integração vertical entre Builder e Validator na BSC. A BlockSec analisou a distribuição dos blocos produzidos por Builders em todos os Validators entre 1º de dezembro, 00:00:00 (UTC), e 18 de dezembro, 00:00:00 (UTC). Os dados mostram que alguns nós validadores apresentam estatísticas de produção de blocos que se desviam significativamente da média do mercado, indicando a existência de integração vertical.
Por exemplo:
- A Nodereal possui uma participação de 100% com a TWStaking.
- A Bloxroute possui uma participação de 100% com a Figment.
- A 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 mais comum entre Searcher e Builder observada na Ethereum. Especificamente, o mecanismo de integração entre Builder e Validator pode ser explorado para controlar o fluxo de transações, transmitindo transações apenas para Validators específicos. Isso pode 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ções de 0 Gwei
O mecanismo de transação de 0 Gwei, embora reduza custos, cria oportunidades de exploração por contratos de phishing. Com transações de 0 Gwei, os 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 de 0 Gwei. Inicialmente, esses contratos se aproveitavam do serviço de transação de 0 Gwei da 48Club ao possuir Koge. Embora a 48Club tenha implementado certas restrições, no momento em que este artigo foi escrito, ainda observamos diversas atividades de phishing sendo realizadas por meio do serviço de transação de 0 Gwei da 48Club, representando uma ameaça significativa à segurança da BSC.
Ataques MEV Estão se Tornando Mais Descontrolados, Especialmente Ataques Sandwich
O atual mecanismo PBS da BSC reformulou o mercado de ataques MEV, tornando essencial que os usuários compreendam as estratégias de proteção contra MEV nessa nova estrutura. Entre os diversos tipos de ataques MEV, o ataque sandwich é um dos mais notórios na blockchain.
Como Funciona um Ataque Sandwich:
- Monitoramento da Transação-Alvo: O atacante monitora o pool de transações (mempool) da blockchain para identificar transações-alvo. Esses alvos são geralmente grandes transações de swap de tokens (por exemplo, troca de ETH por USDT em uma DEX).
- Front-Running 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.
- Back-Running da 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: Harvesting MEV Bots by Exploiting Vulnerabilities in Flashbots Relay.
Antes da implementação do PBS, as transações eram totalmente expostas no pool público de transações, 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 a execução de 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 privado de transações visível apenas aos Builders. Isso garante que as transações permaneçam ocultas dos atacantes (a menos que um Builder as revele deliberadamente), fornecendo uma camada de proteção contra MEV para as transações dos usuários.
Observamos que um bot sandwich de destaque (0x00000000004e660d7929B04626BbF28CBECCe534), que anteriormente realizava ataques sandwich controlando os preços de gas, cessou completamente suas operações há mais de 100 dias. Isso indica que o mecanismo PBS na BSC reformulou o cenário de ataques MEV.
No entanto, ao observar o comportamento on-chain e analisar dados estatísticos (por exemplo, da Dune Analytics), descobrimos que, após a implementação do PBS (maio de 2024), o número de transações de ataque sandwich na cadeia BSC aumentou significativamente. Esse paradoxo destaca uma lacuna crítica nas atuais estratégias de proteção contra MEV na BSC.
O principal motivo para o aumento dos ataques sandwich é que a maioria dos traders e equipes de projeto não utilizou de forma eficaz os canais privados fornecidos pelo PBS. Em vez disso, eles continuam enviando transações para o pool público de transações. Para os atacantes, o custo de obter oportunidades de ataque não aumentou significativamente.
Pelo contrário, os atacantes exploram a capacidade do Builder de aceitar bundles, empacotando tanto a transação-alvo quanto a transação de ataque em um único bundle submetido ao Builder. Se o bundle for incluído com sucesso on-chain, o ataque sandwich é bem-sucedido. Se falhar, o Searcher não sofre nenhuma perda. Isso torna os ataques sandwich mais econômicos e eficientes, reforçando ainda mais a necessidade de uma proteção contra MEV robusta.
Conclusão
Mais de um ano após a entrada em vigor do BEP-322, o PBS remodelou a produção de blocos da BSC: um mercado de Builders se formou e se consolidou, e o conjunto de validadores e o mercado de Builders estão agora intimamente interligados. O custo dessa mudança é um novo conjunto de riscos estruturais — a integração vertical entre Builders e validadores, o mecanismo de transação de 0 Gwei e ataques sandwich que se tornaram mais frequentes, em vez de diminuírem. Se esses riscos permanecerão contidos depende menos do próprio mecanismo e mais de quanto do ecossistema realmente adota os canais privados que o PBS disponibiliza.
