BNB Smart Chain (BSC) implementó BEP-322, el mecanismo de Separación Proponente-Constructor (PBS), a principios de 2024. Esta actualización fundamental dio lugar al mercado de Builders de BSC e introdujo nuevas dinámicas en el ecosistema. Como empresa líder en seguridad blockchain, BlockSec monitorea continuamente el desarrollo de BSC, analizando los posibles riesgos derivados mediante el estudio del mecanismo PBS y su ecosistema en evolución. Nuestro objetivo es proporcionar recomendaciones sólidas de mitigación de riesgos para mejorar la seguridad de BSC.
El panorama en evolución de los validadores y builders de BSC
Los validadores de BSC tienen una influencia significativa dentro del ecosistema de BSC. El umbral de entrada para los validadores de BSC es notablemente alto, manteniéndose su número constantemente entre 40 y 50. En comparación con los millones de nodos validadores de Ethereum, los validadores de BSC ejercen una influencia más fuerte sobre el ecosistema on-chain debido a su poder concentrado.
Tras meses de intensa competencia, el mercado de Builders de BSC ha formado una estructura estable. Actores líderes como Blockrazor y 48Club-pussaint ahora contribuyen con casi el 80% de la construcción de bloques, mientras que Bloxroute, Blocksmith y Nodereal representan colectivamente aproximadamente el 19%. Los actores de cola solo contribuyen de forma esporádica. El análisis de BlockSec también ha destacado el fenómeno de la integración vertical entre Validators y Builders en la cadena BSC, lo cual podría exacerbar aún más los riesgos de centralización e impactar la seguridad general de BNB Smart Chain.
El nuevo mecanismo también ha introducido riesgos en las transacciones on-chain, dando lugar a la aparición de productos de prevención de riesgos. El mecanismo único de transacciones de 0 Gwei de BSC reduce los costos de transacción, pero desafortunadamente ha provocado actividades de phishing frecuentes. Bajo el mecanismo PBS, el proceso mediante el cual el Builder recibe paquetes de transacciones ha reducido el costo de los ataques sandwich, haciendo que las transacciones sean más susceptibles a este tipo de ataques. Esto, a su vez, ha impulsado el desarrollo de productos de RPC privado destinados a mitigar el Valor Máximo Extraíble (MEV) y reforzar la seguridad de BSC.
Diferencias clave entre las implementaciones de PBS en BSC y Ethereum
Un buen punto de comparación para el mecanismo PBS de BSC es Ethereum. Aunque BSC ha adoptado la mayoría de los principios de implementación de Ethereum, aún existen diferencias detalladas, particularmente en los mecanismos de consenso y la topología de la red de validadores. Comprender estas distinciones es crucial para entender las características de rendimiento únicas de BNB Smart Chain tras PBS.
Eliminación del mecanismo de Relay
Dado el número relativamente pequeño de validadores en BSC, no es necesario un Relay centralizado para reducir la complejidad de comunicación entre Builders y Validators. Además, los intervalos de bloque más cortos de BSC significan que usar un Relay para reenviar transacciones en realidad aumentaría los enlaces de comunicación y extendería el tiempo de interacción.
Como complemento al Relay, BSC introdujo el servicio mev-sentry, en el que cada validador opera su propio sentry. Este servicio sentry interactúa directamente con los Builders, y su separación del Validator proporciona una protección mejorada. A diferencia de un Relay, los Validators pueden obtener directamente el contenido del bloque a partir de las ofertas de los Builders a través del sentry, lo que les permite verificar de forma independiente la validez de las ofertas de los Builders. Esto salvaguarda aún más los intereses de los Validators. Durante cada intervalo de bloque, se permite a los Builders enviar no más de tres ofertas al sentry, lo que genera diferencias significativas en las estrategias de puja entre los Builders de BSC y los Builders de Ethereum.
Diferencias en la configuración de transferencia de coinbase
En el mecanismo PBS de Ethereum, se permite a los Builders cambiar la dirección de coinbase a la suya propia, lo que permite que las tarifas de prioridad de Ethereum sean ejecutadas y redistribuidas por los Builders. Sin embargo, el mecanismo PBS de BSC no tiene esta capacidad, lo que limita en cierta medida la flexibilidad de puja y asignación de los Builders.
Compatibilidad con transacciones de 0 Gwei
Antes de la actualización BEP-322, el mecanismo de transacciones de 0 Gwei fue introducido inicialmente por 48Club como una función de membresía, ofrecida como un servicio especial por parte de los Validators a los poseedores del token KOGE.
Después de la actualización BEP-322, se permitió a todos los Validators de BSC aceptar bloques que contuvieran transacciones de 0 Gwei. A diferencia del mecanismo dinámico de Base Fee de Ethereum, el Base Fee de las transacciones en BSC se establece en 0 por defecto, lo que significa que se permiten transacciones con un Gas Price de 0. Como salvaguarda complementaria de un Gas Fee mínimo, BSC ha establecido una restricción según la cual el Effective Gas Price de un bloque no puede caer por debajo de 1. Este mecanismo único permite a los Builders incluir transacciones de 0 Gwei al construir bloques, lo que permite un uso más eficiente del espacio de bloque e impacta la seguridad de BSC.
Desarrollo del mercado de Builders de BSC
De manera similar a Ethereum, tras la implementación de PBS, el mercado de Builders de BSC surgió y atravesó un período de rápido desarrollo, formando finalmente una estructura estable.
Según las estadísticas proporcionadas por Dune, un total de 8 actores Builder han participado en el mercado de Builders de BSC. En las primeras etapas de la implementación de PBS, Nodereal, Blocksmith y Blockrazor dominaron brevemente todo el mercado. Sin embargo, con la incorporación de 48Club y Bloxroute a la competencia a finales de junio, el mercado entró en una fase de disputa.
A día de hoy, Blockrazor y 48Club representan más del 80% de la construcción de bloques en BSC, consolidándose como los principales actores en el mercado de Builders. Mientras tanto, Bloxroute, Blocksmith y Nodereal se han convertido en actores de "nivel 2", mientras que Jetbldr, Blockbus y Darwin solo contribuyen de forma esporádica a la producción de bloques. Esta consolidación influye significativamente en el rendimiento de BSC tras PBS.
Desarrollo de los validadores de BSC
A diferencia de Ethereum, el número de validadores en BSC se mantiene dentro de un rango estable debido a las diferencias en los umbrales de entrada. En Ethereum, cualquiera puede convertirse en validador haciendo staking de 32 ETH, lo que ha resultado en que el número de validadores supere el millón. Los validadores de Ethereum se integran con los Relays para conectarse con los Builders, recibir propuestas de bloque y completar la producción de bloques.
En BSC, sin embargo, convertirse en validador requiere hacer staking de una gran cantidad de BNB, lo que eleva significativamente la barrera de entrada. Actualmente, solo hay 45 validadores en BSC, de los cuales 21 están clasificados como Cabinet y los 24 restantes como Candidates. Según las estadísticas de BSCScan, estos 45 validadores tienen en conjunto 29,244,219 BNB en staking (a fecha de 18 de diciembre de 2024), y el validador con la menor cantidad en staking aún posee 73,446 BNB.
Esta diferencia en la concentración de validadores ha dado lugar, en cierta medida, a diferencias ecológicas entre BSC y Ethereum. Por ejemplo, en BSC, el menor costo de vincular Builders y Validators elimina el espacio de mercado para los servicios de Relay. Al mismo tiempo, la alta influencia de los validadores implica que el desarrollo del ecosistema on-chain debe priorizar los intereses de los validadores. Esto podría afectar la competitividad y el entusiasmo de otros equipos de proyectos dentro del ecosistema colaborativo de la cadena pública, además de los grupos de validadores, planteando un desafío para la seguridad a largo plazo de BNB Smart Chain.
Riesgos potenciales en cadena tras la implementación de PBS
La implementación completa de PBS en BSC, si bien ha traído mejoras arquitectónicas, también ha sacado a la luz varios riesgos potenciales que requieren atención, particularmente en lo que respecta a la seguridad de BSC.
Integración vertical Builder-Validator
Existe un fenómeno significativo de integración vertical Builder-Validator en BSC. BlockSec analizó la distribución de bloques producidos por Builders en todos los Validators desde el 1 de diciembre a las 00:00:00 (UTC) hasta el 18 de diciembre a las 00:00:00 (UTC). Los datos muestran que algunos nodos validadores tienen estadísticas de producción de bloques que se desvían significativamente del promedio del mercado, lo que indica la existencia de integración vertical.
Por ejemplo:
- Nodereal tiene una cuota del 100% con TWStaking.
- Bloxroute tiene una cuota del 100% con Figment.
- 48Club posee más del 90% de cuota con Turing, The48Club, Shannon, Lista, Feynman y Avengers.
Los riesgos potenciales derivados de esta integración vertical difieren de la integración más común entre Searcher y Builder que se observa en Ethereum. Específicamente, el mecanismo de integración Builder-Validator podría ser explotado para controlar el flujo de transacciones, transmitiendo transacciones solo a Validators específicos. Esto podría generar pérdidas para los intereses de los usuarios y exacerbar los riesgos de centralización, impactando directamente la seguridad de BNB Smart Chain.
Riesgos del mecanismo de transacciones de 0 Gwei
El mecanismo de transacciones de 0 Gwei, si bien reduce los costos, crea oportunidades de explotación por parte de contratos de phishing. Con transacciones de 0 Gwei, los contratos de phishing pueden transferir fondos sin costo alguno, agravando la prevalencia de los ataques de phishing.
En BSC, BlockSec ya ha detectado múltiples contratos de phishing que utilizan transacciones de 0 Gwei. Inicialmente, estos contratos aprovechaban el servicio de transacciones de 0 Gwei de 48Club manteniendo Koge. Aunque 48Club ha implementado ciertas restricciones, al momento de escribir este artículo, seguimos observando varias actividades de phishing llevadas a cabo a través del servicio de transacciones de 0 Gwei de 48Club, lo que representa una amenaza significativa para la seguridad de BSC.
Los ataques MEV se vuelven más rampantes, especialmente los ataques sandwich
El mecanismo PBS de BSC actual ha reconfigurado el mercado de ataques MEV, haciendo esencial que los usuarios comprendan las estrategias de protección contra MEV bajo esta nueva estructura. Entre los diversos ataques MEV, el ataque sandwich es uno de los más notorios en blockchain.
Cómo funciona un ataque sandwich:
- Monitoreo de la transacción objetivo: El atacante monitorea el pool de transacciones de la blockchain (mempool) para identificar transacciones objetivo. Estos objetivos suelen ser transacciones grandes de intercambio de tokens (por ejemplo, intercambiar ETH por USDT en un DEX).
- Front-running de la transacción objetivo: El atacante envía una transacción antes de la transacción objetivo (front-running) para influir en el precio de mercado. Por ejemplo, el atacante compra el token objetivo, haciendo subir su precio.
- Back-running de la transacción objetivo: Después de que se ejecuta la transacción objetivo, el atacante envía otra transacción después de ella (back-running) para vender los tokens adquiridos en el paso de front-running. Esto le permite al atacante beneficiarse de las fluctuaciones de precio provocadas por la transacción objetivo.
Para más información sobre MEV, lea nuestro análisis detallado: Harvesting MEV Bots by Exploiting Vulnerabilities in Flashbots Relay.
Antes de la implementación de PBS, las transacciones estaban completamente expuestas en el pool de transacciones público, quedando visibles para los atacantes. Los atacantes podían analizar todas las transacciones rentables y manipular el orden de las transacciones controlando el gas price, lo que les permitía llevar a cabo ataques.
El mecanismo PBS de BSC introduce un canal privado para las transacciones, que permite a los usuarios enviar sus transacciones a un pool de transacciones privado que solo es visible para los Builders. Esto garantiza que las transacciones permanezcan ocultas de los atacantes (a menos que un Builder las filtre deliberadamente), proporcionando una capa de protección contra MEV para las transacciones de los usuarios.
Observamos que un bot sandwich líder (0x00000000004e660d7929B04626BbF28CBECCe534), que anteriormente llevaba a cabo ataques sandwich controlando los gas prices, cesó por completo sus operaciones hace más de 100 días. Esto indica que el mecanismo PBS en BSC ha reconfigurado el panorama de los ataques MEV.
Sin embargo, al observar el comportamiento on-chain y analizar datos estadísticos (por ejemplo, Dune Analytics), descubrimos que tras la implementación de PBS (mayo de 2024), el número de transacciones de ataques sandwich en la cadena BSC ha aumentado significativamente. Esta paradoja pone de relieve una brecha crítica en las actuales estrategias de protección contra MEV en BSC.
La razón principal del aumento de los ataques sandwich es que la mayoría de los traders y equipos de proyectos no han utilizado de manera efectiva los canales privados que proporciona PBS. En cambio, continúan enviando transacciones al pool de transacciones público. Para los atacantes, el costo de obtener oportunidades de ataque no ha aumentado significativamente.
Por el contrario, los atacantes explotan la capacidad del Builder para aceptar bundles empaquetando tanto la transacción objetivo como la transacción de ataque en un único bundle enviado al Builder. Si el bundle se incluye con éxito on-chain, el ataque sandwich tiene éxito. Si falla, el Searcher no incurre en pérdida alguna. Esto hace que los ataques sandwich sean más rentables y eficientes, lo que subraya aún más la necesidad de una sólida protección contra MEV.
Conclusión
Más de un año después de que BEP-322 entrara en vigor, PBS ha reconfigurado la producción de bloques de BSC: se ha formado y consolidado un mercado de Builders, y el conjunto de validadores y el mercado de Builders ahora están estrechamente entrelazados. La contrapartida es un conjunto de nuevos riesgos estructurales: la integración vertical entre Builders y validadores, el mecanismo de transacciones de 0 Gwei, y los ataques sandwich, que se han vuelto más frecuentes en lugar de menos. Que estos riesgos se mantengan contenidos depende menos del mecanismo en sí que de cuánto del ecosistema adopte realmente los canales privados que PBS pone a disposición.
