BNB Smart Chain (BSC) implementierte Anfang 2024 BEP-322, den Proposer-Builder-Separation-Mechanismus (PBS). Dieses entscheidende Upgrade führte zur Entstehung des BSC Builder-Marktes und brachte neue Dynamiken innerhalb des Ökosystems mit sich. Als führendes Unternehmen im Bereich der Blockchain-Sicherheit beobachtet BlockSec kontinuierlich die Entwicklung von BSC und analysiert potenzielle Folgerisiken durch die Untersuchung des PBS-Mechanismus und seines sich weiterentwickelnden Ökosystems. Unser Ziel ist es, fundierte Empfehlungen zur Risikominderung zu geben, um die BSC-Sicherheit zu verbessern.
Die sich wandelnde Landschaft der BSC-Validatoren und -Builder
BSC-Validatoren haben einen erheblichen Einfluss innerhalb des BSC-Ökosystems. Die Eintrittsschwelle für BSC-Validatoren ist bemerkenswert hoch, wobei ihre Anzahl konstant bei etwa 40-50 liegt. Im Vergleich zu den Millionen von Validator-Knoten bei Ethereum üben BSC-Validatoren aufgrund ihrer konzentrierten Macht einen stärkeren Einfluss auf das On-Chain-Ökosystem aus.
Nach monatelangem intensivem Wettbewerb hat sich der BSC Builder-Markt zu einer stabilen Struktur entwickelt. Führende Akteure wie Blockrazor und 48Club-pussaint tragen inzwischen fast 80 % der Block-Erstellung bei, während Bloxroute, Blocksmith und Nodereal zusammen etwa 19 % ausmachen. Nachzügler tragen nur sporadisch bei. Die Analyse von BlockSec hat auch das Phänomen der vertikalen Integration zwischen Validatoren und Buildern auf der BSC-Chain hervorgehoben, was Zentralisierungsrisiken weiter verschärfen und die allgemeine BNB Smart Chain-Sicherheit beeinträchtigen könnte.
Der neue Mechanismus hat auch On-Chain-Transaktionsrisiken mit sich gebracht, was zur Entstehung von Produkten zur Risikoprävention geführt hat. Der einzigartige 0-Gwei-Transaktionsmechanismus von BSC senkt die Transaktionskosten, hat jedoch leider auch zu häufigen Phishing-Aktivitäten geführt. Unter dem PBS-Mechanismus hat der Prozess des Empfangs von Transaktionsbündeln durch den Builder die Kosten für Sandwich-Angriffe gesenkt, wodurch Transaktionen anfälliger für solche Angriffe geworden sind. Dies hat wiederum die Entwicklung von Privacy-RPC-Produkten vorangetrieben, die darauf abzielen, Maximum Extractable Value (MEV) zu mindern und die BSC-Sicherheit zu stärken.
Wesentliche Unterschiede zwischen den PBS-Implementierungen von BSC und Ethereum
Ein guter Vergleichspunkt für den BSC-PBS-Mechanismus ist Ethereum. Während BSC die meisten der Implementierungsprinzipien von Ethereum übernommen hat, gibt es weiterhin detaillierte Unterschiede, insbesondere bei den Konsensmechanismen und der Netzwerktopologie der Validatoren. Das Verständnis dieser Unterschiede ist entscheidend, um die einzigartigen Leistungsmerkmale von BNB Smart Chain nach PBS zu erfassen.
Wegfall des Relay-Mechanismus
Angesichts der relativ geringen Anzahl von Validatoren auf BSC besteht keine Notwendigkeit für ein zentralisiertes Relay, um die Kommunikationskomplexität zwischen Buildern und Validatoren zu reduzieren. Zudem bedeuten die kürzeren Blockintervalle von BSC, dass die Verwendung eines Relays zur Weiterleitung von Transaktionen tatsächlich die Kommunikationsverbindungen erhöhen und die Interaktionszeit verlängern würde.
Als Ergänzung zum Relay hat BSC den mev-sentry-Dienst eingeführt, bei dem jeder Validator seinen eigenen Sentry betreibt. Dieser Sentry-Dienst interagiert direkt mit Buildern, und seine Trennung vom Validator bietet einen erhöhten Schutz. Im Gegensatz zu einem Relay können Validatoren den Blockinhalt aus den Geboten der Builder direkt über den Sentry abrufen, wodurch sie die Gültigkeit der Builder-Gebote eigenständig überprüfen können. Dies schützt die Interessen der Validatoren zusätzlich. Während jedes Blockintervalls dürfen Builder nicht mehr als drei Gebote an den Sentry senden, was zu erheblichen Unterschieden in den Gebotsstrategien zwischen BSC-Buildern und Ethereum-Buildern führt.
Unterschiede bei den Coinbase-Transfer-Einstellungen
Im PBS-Mechanismus von Ethereum ist es Buildern erlaubt, die Coinbase-Adresse in ihre eigene zu ändern, wodurch Ethereums Priority Fees von Buildern ausgeführt und umverteilt werden können. Der PBS-Mechanismus von BSC verfügt jedoch nicht über diese Möglichkeit, was die Flexibilität der Builder bei Geboten und Zuweisungen etwas einschränkt.
Unterstützung von 0-Gwei-Transaktionen
Vor dem BEP-322-Upgrade wurde der 0-Gwei-Transaktionsmechanismus ursprünglich von 48Club als Mitgliedschaftsfunktion eingeführt und von Validatoren als besonderer Service für KOGE-Token-Inhaber angeboten.
Nach dem BEP-322-Upgrade wurde allen BSC-Validatoren erlaubt, Blocks mit 0-Gwei-Transaktionen zu akzeptieren. Im Gegensatz zu Ethereums dynamischem Base-Fee-Mechanismus ist die Base Fee für Transaktionen auf BSC standardmäßig auf 0 gesetzt, was bedeutet, dass Transaktionen mit einem Gas Price von 0 zulässig sind. Um dies als Mindestschutz für die Gasgebühr zu ergänzen, hat BSC eine Beschränkung eingeführt, wonach der Effective Gas Price eines Blocks nicht unter 1 fallen darf. Dieser einzigartige Mechanismus ermöglicht es Buildern, 0-Gwei-Transaktionen bei der Blockerstellung einzubeziehen, was eine effizientere Nutzung des Blockplatzes ermöglicht und die BSC-Sicherheit beeinflusst.
Entwicklung des BSC Builder-Marktes
Ähnlich wie bei Ethereum entstand nach der Einführung von PBS der BSC Builder-Markt und durchlief eine Phase rascher Entwicklung, bis er schließlich eine stabile Struktur bildete.
Laut den von Dune bereitgestellten Statistiken haben insgesamt 8 Builder-Akteure am BSC-Builder-Markt teilgenommen. In den frühen Phasen der PBS-Einführung dominierten Nodereal, Blocksmith und Blockrazor kurzzeitig den gesamten Markt. Mit dem Beitritt von 48Club und Bloxroute zum Wettbewerb Ende Juni trat der Markt jedoch in eine Phase des Tauziehens ein.
Derzeit machen Blockrazor und 48Club über 80 % der Block-Erstellung auf BSC aus und etablieren sich damit als führende Akteure im Builder-Markt. Gleichzeitig sind Bloxroute, Blocksmith und Nodereal zu „Tier-2“-Akteuren geworden, während Jetbldr, Blockbus und Darwin nur sporadisch zur Blockproduktion beitragen. Diese Konsolidierung beeinflusst die Performance von BSC nach PBS erheblich.
Entwicklung der BSC-Validatoren
Im Gegensatz zu Ethereum bleibt die Anzahl der Validatoren auf BSC aufgrund unterschiedlicher Eintrittsschwellen in einem stabilen Bereich. Auf Ethereum kann jeder durch das Staken von 32 ETH Validator werden, wodurch die Anzahl der Validatoren die Marke von 1 Million überschritten hat. Ethereum-Validatoren integrieren sich mit Relays, um sich mit Buildern zu verbinden, Blockvorschläge zu erhalten und die Blockproduktion abzuschließen.
Auf BSC hingegen erfordert das Werden zum Validator das Staken einer großen Menge an BNB, was die Eintrittsbarriere erheblich erhöht. Derzeit gibt es nur 45 Validatoren auf BSC, von denen 21 als Cabinet und die restlichen 24 als Candidates eingestuft werden. Laut Statistiken von BSCScan haben diese 45 Validatoren zusammen 29.244.219 BNB gestakt (Stand: 18. Dezember 2024), wobei der Validator mit dem geringsten Betrag immer noch 73.446 BNB hält.
Dieser Unterschied bei der Konzentration der Validatoren hat bis zu einem gewissen Grad zu ökologischen Unterschieden zwischen BSC und Ethereum geführt. So entfällt beispielsweise auf BSC durch die geringeren Kosten für die Verbindung von Buildern und Validatoren der Marktraum für Relay-Dienste. Gleichzeitig bedeutet der hohe Einfluss der Validatoren, dass die Entwicklung des On-Chain-Ökosystems die Interessen der Validatoren priorisieren muss. Dies könnte die Wettbewerbsfähigkeit und den Enthusiasmus anderer Projektteams innerhalb des kollaborativen Ökosystems der Public Chain, abgesehen von den Validator-Gruppen, beeinträchtigen und stellt eine Herausforderung für die langfristige BNB Smart Chain-Sicherheit dar.
Potenzielle On-Chain-Risiken nach der Einführung von PBS
Die vollständige Implementierung von PBS auf BSC hat zwar architektonische Verbesserungen mit sich gebracht, aber auch mehrere potenzielle Risiken zutage gebracht, die besondere Aufmerksamkeit erfordern, insbesondere im Hinblick auf die BSC-Sicherheit.
Vertikale Integration von Builder und Validator
Es gibt ein bedeutendes Phänomen der vertikalen Integration von Builder und Validator auf BSC. BlockSec analysierte die Verteilung der von Buildern erstellten Blocks über alle Validatoren hinweg vom 1. Dezember, 00:00:00 (UTC), bis zum 18. Dezember, 00:00:00 (UTC). Die Daten zeigen, dass die Blockproduktionsstatistiken einiger Validator-Knoten erheblich vom Marktdurchschnitt abweichen, was auf das Vorhandensein einer vertikalen Integration hinweist.
Zum Beispiel:
- Nodereal hat einen Anteil von 100 % mit TWStaking.
- Bloxroute hat einen Anteil von 100 % mit Figment.
- 48Club hält über 90 % Anteile mit Turing, The48Club, Shannon, Lista, Feynman und Avengers.
Die potenziellen Risiken, die sich aus dieser vertikalen Integration ergeben, unterscheiden sich von der bei Ethereum häufiger auftretenden Searcher-Builder-Integration. Konkret könnte der Builder-Validator-Integrationsmechanismus ausgenutzt werden, um den Transaktionsfluss zu kontrollieren und Transaktionen nur an bestimmte Validatoren weiterzuleiten. Dies könnte zu Verlusten bei den Interessen der Nutzer führen und Zentralisierungsrisiken verschärfen, wodurch die BNB Smart Chain-Sicherheit direkt beeinträchtigt wird.
Risiken des 0-Gwei-Transaktionsmechanismus
Der 0-Gwei-Transaktionsmechanismus senkt zwar die Kosten, schafft aber auch Möglichkeiten für den Missbrauch durch Phishing-Verträge. Bei 0-Gwei-Transaktionen können Phishing-Verträge Gelder kostenlos übertragen, was die Verbreitung von Phishing-Angriffen verschärft.
Auf BSC hat BlockSec bereits mehrere Phishing-Verträge entdeckt, die 0-Gwei-Transaktionen nutzen. Zunächst nutzten diese Verträge den 0-Gwei-Transaktionsdienst von 48Club, indem sie Koge hielten. Obwohl 48Club bestimmte Einschränkungen eingeführt hat, beobachten wir zum Zeitpunkt der Erstellung dieses Artikels weiterhin mehrere Phishing-Aktivitäten, die über den 0-Gwei-Transaktionsdienst von 48Club durchgeführt werden, was eine erhebliche Bedrohung für die BSC-Sicherheit darstellt.
MEV-Angriffe nehmen zu, insbesondere Sandwich-Angriffe
Der aktuelle BSC-PBS-Mechanismus hat den Markt für MEV-Angriffe neu geordnet, wodurch es für Nutzer unerlässlich geworden ist, MEV-Schutzstrategien unter dieser neuen Struktur zu verstehen. Unter den verschiedenen MEV-Angriffen ist der Sandwich-Angriff einer der berüchtigtsten in der Blockchain.
Wie ein Sandwich-Angriff funktioniert:
- Überwachung der Zieltransaktion: Der Angreifer überwacht den Transaktionspool (Mempool) der Blockchain, um Zieltransaktionen zu identifizieren. Diese Ziele sind typischerweise große Token-Swap-Transaktionen (z. B. der Tausch von ETH gegen USDT auf einer DEX).
- Front-Running der Zieltransaktion: Der Angreifer sendet eine Transaktion vor der Zieltransaktion (Front-Running), um den Marktpreis zu beeinflussen. Zum Beispiel kauft der Angreifer das Ziel-Token, wodurch dessen Preis steigt.
- Back-Running der Zieltransaktion: Nachdem die Zieltransaktion ausgeführt wurde, sendet der Angreifer eine weitere Transaktion danach (Back-Running), um die im Front-Running-Schritt erworbenen Token zu verkaufen. Dadurch kann der Angreifer von den durch die Zieltransaktion verursachten Preisschwankungen profitieren.
Weitere Informationen zu MEV finden Sie in unserer detaillierten Analyse: Harvesting MEV Bots by Exploiting Vulnerabilities in Flashbots Relay.
Vor der Einführung von PBS waren Transaktionen im öffentlichen Transaktionspool vollständig offengelegt, wodurch sie für Angreifer sichtbar waren. Angreifer konnten alle profitablen Transaktionen analysieren und die Transaktionsreihenfolge durch Kontrolle des Gas Price manipulieren, was ihnen ermöglichte, Angriffe durchzuführen.
Der BSC-PBS-Mechanismus führt einen Privacy-Kanal für Transaktionen ein, der es Nutzern ermöglicht, ihre Transaktionen an einen privaten Transaktionspool zu senden, der nur für Builder sichtbar ist. Dadurch wird sichergestellt, dass Transaktionen vor Angreifern verborgen bleiben (sofern ein Builder sie nicht absichtlich weitergibt), was eine Ebene des MEV-Schutzes für Nutzertransaktionen bietet.
Wir haben beobachtet, dass ein führender Sandwich-Bot (0x00000000004e660d7929B04626BbF28CBECCe534), der zuvor Sandwich-Angriffe durch die Kontrolle des Gas Price durchführte, vor über 100 Tagen den Betrieb vollständig eingestellt hat. Dies deutet darauf hin, dass der PBS-Mechanismus auf BSC die Landschaft der MEV-Angriffe neu geordnet hat.
Durch die Beobachtung von On-Chain-Verhalten und die Analyse statistischer Daten (z. B. Dune Analytics) haben wir jedoch festgestellt, dass die Anzahl der Sandwich-Angriffstransaktionen auf der BSC-Chain nach der Einführung von PBS (Mai 2024) deutlich zugenommen hat. Dieses Paradoxon verdeutlicht eine kritische Lücke in den aktuellen MEV-Schutzstrategien auf BSC.
Der Hauptgrund für den Anstieg der Sandwich-Angriffe ist, dass die meisten Trader und Projektteams die von PBS bereitgestellten Privacy-Kanäle nicht effektiv nutzen. Stattdessen senden sie weiterhin Transaktionen an den öffentlichen Transaktionspool. Für Angreifer haben sich die Kosten, um Angriffsmöglichkeiten zu erhalten, nicht wesentlich erhöht.
Im Gegenteil nutzen Angreifer die Fähigkeit des Builders, Bundles zu akzeptieren, indem sie sowohl die Zieltransaktion als auch die Angriffstransaktion in ein einziges Bundle verpacken, das an den Builder übermittelt wird. Wird das Bundle erfolgreich in die Chain aufgenommen, ist der Sandwich-Angriff erfolgreich. Schlägt es fehl, entsteht dem Searcher kein Verlust. Dies macht Sandwich-Angriffe kostengünstiger und effizienter und unterstreicht zusätzlich die Notwendigkeit eines robusten MEV-Schutzes.
Fazit
Mehr als ein Jahr nach dem Inkrafttreten von BEP-322 hat PBS die Blockproduktion von BSC neu geformt: Ein Builder-Markt hat sich gebildet und konsolidiert, und die Gruppe der Validatoren sowie der Builder-Markt sind nun eng miteinander verflochten. Der Preis dafür ist eine Reihe neuer struktureller Risiken – vertikale Integration zwischen Buildern und Validatoren, der 0-Gwei-Transaktionsmechanismus sowie Sandwich-Angriffe, die häufiger geworden sind, statt seltener. Ob diese Risiken eingedämmt bleiben, hängt weniger vom Mechanismus selbst ab als davon, in welchem Umfang das Ökosystem die von PBS bereitgestellten Privacy-Kanäle tatsächlich nutzt.
