Leistung des BSC nach vollständiger PBS-Implementierung?

BNB Smart Chain (BSC) hat Anfang 2024 den BEP-322, den Proposer-Builder Separation (PBS) Mechanismus, implementiert. Dieses entscheidende Upgrade führte zum BSC Builder-Markt und führte neue Ökosystemdynamiken ein. Als führendes Blockchain-Sicherheitsunternehmen überwacht BlockSec kontinuierlich die Entwicklung von BSC und analysiert potenzielle Derivativrisiken, indem es den PBS-Mechanismus und sein sich entwickelndes Ökosystem untersucht. Unser Ziel ist es, robuste Empfehlungen zur Risikominderung zu geben, um die Sicherheit von BSC zu verbessern.

Die sich entwickelnde Landschaft von BSC-Validatoren und -Buildern

BSC-Validatoren haben erheblichen Einfluss im BSC-Ökosystem. Die Eintrittsschwelle für BSC-Validatoren ist bemerkenswert hoch, und ihre Anzahl wird konstant bei etwa 40-50 gehalten. Im Vergleich zu den Millionen von Validator-Nodes von Ethereum üben BSC-Validatoren aufgrund ihrer konzentrierten Macht einen stärkeren Einfluss auf das On-Chain-Ökosystem aus.

Nach Monaten intensiven Wettbewerbs hat sich der BSC Builder-Markt zu einer stabilen Struktur entwickelt. Führende Akteure wie Blockrazor und 48Club-pussaint tragen nun fast 80 % des Blockaufbaus bei, während Bloxroute, Blocksmith und Nodereal zusammen etwa 19 % ausmachen. Akteure am Ende tragen nur sporadisch bei. Die Analyse von BlockSec hat auch das Phänomen der vertikalen Integration zwischen Validatoren und Buildern auf der BSC-Kette hervorgehoben, was die Zentralisierungsrisiken weiter verschärfen und die allgemeine Sicherheit der BNB Smart Chain beeinträchtigen kann.

Der neue Mechanismus hat auch On-Chain-Transaktionsrisiken eingeführt, was zur Entstehung von Risikopräventionsprodukten geführt hat. Der einzigartige 0 Gwei Transaktionsmechanismus von BSC reduziert die Transaktionskosten, hat aber leider zu häufigen Phishing-Aktivitäten geführt. Unter dem PBS-Mechanismus hat der Prozess des Empfangens von Transaktionsbündeln durch den Builder die Kosten für Sandwich-Angriffe gesenkt, wodurch Transaktionen anfälliger für solche Angriffe werden. Dies wiederum hat die Entwicklung von Privacy-RPC-Produkten vorangetrieben, die darauf abzielen, Maximum Extractable Value (MEV) zu mindern und die Sicherheit von BSC zu stärken.

Hauptunterschiede zwischen PBS-Implementierungen von BSC und Ethereum

Ein guter Vergleichspunkt für den BSC PBS-Mechanismus ist Ethereum. Während BSC die meisten Implementierungsprinzipien von Ethereum übernommen hat, gibt es immer noch detaillierte Unterschiede, insbesondere bei Konsensmechanismen und der Topologie des Validator-Netzwerks. Das Verständnis dieser Unterschiede ist entscheidend, um die einzigartigen Leistungsmerkmale der BNB Smart Chain nach PBS zu erfassen.

Eliminierung des Relay-Mechanismus

Angesichts der relativ geringen Anzahl von Validatoren auf BSC ist kein zentralisiertes Relay erforderlich, um die Kommunikationskomplexität zwischen Buildern und Validatoren zu reduzieren. Darüber hinaus bedeuten die kürzeren Blockintervalle von BSC, dass die Verwendung eines Relay zum Weiterleiten 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 den Buildern, und seine Trennung vom Validator bietet verbesserten Schutz. Im Gegensatz zu einem Relay können Validatoren über den Sentry direkt Blockinhalte von Builder-Geboten abrufen, wodurch sie die Gültigkeit von Builder-Geboten unabhängig überprüfen können. Dies schützt die Interessen der Validatoren weiter. Während jedes Blockintervalls dürfen Builder nicht mehr als drei Gebote an den Sentry senden, was zu erheblichen Unterschieden in den Bietstrategien zwischen BSC Buildern und Ethereum Buildern führt.

Unterschiede bei den Coinbase-Transfer-Einstellungen

Im PBS-Mechanismus von Ethereum dürfen Builder die Coinbase-Adresse in ihre eigene ändern, wodurch die Prioritätsgebühren von Ethereum von den Buildern ausgeführt und neu verteilt werden können. Der PBS-Mechanismus von BSC verfügt jedoch nicht über diese Fähigkeit, was die Biet- und Zuweisungsflexibilität der Builder bis zu einem gewissen Grad einschränkt.

Unterstützung für 0 Gwei-Transaktionen

Vor dem BEP-322-Upgrade wurde der 0 Gwei Transaktionsmechanismus ursprünglich von 48Club als Mitgliedschaftsfunktion eingeführt, die von den Validatoren als spezieller Service für KOGE-Token-Inhaber angeboten wurde.

Nach dem BEP-322-Upgrade durften alle BSC-Validatoren Blöcke mit 0 Gwei-Transaktionen akzeptieren. Im Gegensatz zum dynamischen Base-Fee-Mechanismus von Ethereum ist die Transaktions-Base-Fee von BSC standardmäßig auf 0 eingestellt, was bedeutet, dass Transaktionen mit einem Gaspreis von 0 zulässig sind. Als Ergänzung dazu als Mindestgebührenschutz hat BSC eine Beschränkung festgelegt, dass der effektive Gaspreis eines Blocks nicht unter 1 fallen darf. Dieser einzigartige Mechanismus ermöglicht es Buildern, 0 Gwei-Transaktionen beim Erstellen von Blöcken einzuschließen, was eine effizientere Nutzung des Blockraums ermöglicht und die Sicherheit von BSC beeinflusst.

Entwicklung des BSC Builder-Marktes

Ähnlich wie bei Ethereum entstand nach der Implementierung von PBS der BSC Builder-Markt und erlebte eine Phase rapider Entwicklung, die schließlich zu einer stabilen Struktur führte.

Laut Statistiken von Dune haben insgesamt 8 Builder-Spieler am BSC Builder-Markt teilgenommen. In den frühen Phasen der PBS-Implementierung dominierten Nodereal, Blocksmith und Blockrazor kurzzeitig den gesamten Markt. Mit dem Eintritt von 48Club und Bloxroute in den Wettbewerb Ende Juni trat der Markt in eine Patt-Phase ein.

Derzeit machen Blockrazor und 48Club über 80 % des Blockaufbaus auf BSC aus und haben sich als führende Akteure auf dem Builder-Markt etabliert. Unterdessen sind Bloxroute, Blocksmith und Nodereal zu "Tier-2"-Akteuren geworden, während Jetbldr, Blockbus und Darwin nur sporadisch zur Blockproduktion beitragen. Diese Konsolidierung beeinflusst maßgeblich die Leistung von BSC nach PBS.

Entwicklung von BSC-Validatoren

Im Gegensatz zu Ethereum liegt die Anzahl der Validatoren auf BSC aufgrund von Unterschieden bei den Eintrittsschwellen in einem stabilen Bereich. Auf Ethereum kann jeder Validator werden, indem er 32 ETH stakt, was dazu führt, dass die Anzahl der Validatoren 1 Million übersteigt. Ethereum-Validatoren integrieren sich in Relays, um sich mit Buildern zu verbinden, Blockvorschläge zu erhalten und die Blockproduktion abzuschließen.

Auf BSC erfordert die Ernennung zum Validator jedoch das Staken einer großen Menge BNB, was die Eintrittsschranke erheblich erhöht. Derzeit gibt es nur 45 Validatoren auf BSC, von denen 21 als Cabinet und die übrigen 24 als Candidates klassifiziert sind. Laut Statistiken von BSCScan haben diese 45 Validatoren kollektiv 29.244.219 BNB gestaket (Stand 18. Dezember 2024), wobei der Validator mit dem geringsten Einsatz immer noch 73.446 BNB hält.

Dieser Unterschied in der Validator-Konzentration hat bis zu einem gewissen Grad zu ökologischen Unterschieden zwischen BSC und Ethereum geführt. Beispielsweise eliminiert auf BSC die geringeren Kosten für die Verknüpfung von Buildern und Validatoren den Markt für Relay-Dienste. Gleichzeitig bedeutet der hohe Einfluss der Validatoren, dass die Entwicklung des On-Chain-Ökosystems den Interessen der Validatoren Priorität einräumen 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 eine Herausforderung für die langfristige Sicherheit der BNB Smart Chain darstellen.

Potenzielle On-Chain-Risiken nach der PBS-Implementierung

Die vollständige Implementierung von PBS auf BSC hat zwar architektonische Verbesserungen gebracht, aber auch mehrere potenzielle Risiken aufgedeckt, die Aufmerksamkeit erfordern, insbesondere in Bezug auf die Sicherheit von BSC.

Vertikale Integration von Builder-Validatoren

Es gibt ein signifikantes Phänomen der vertikalen Integration von Builder-Validatoren auf BSC. BlockSec analysierte die Verteilung von von Buildern produzierten Blöcken über alle Validatoren vom 1. Dezember, 00:00:00 (UTC) bis zum 18. Dezember, 00:00:00 (UTC). Die Daten zeigen, dass einige Validator-Nodes Blockproduktionsstatistiken aufweisen, die erheblich vom Marktdurchschnitt abweichen, was auf das Vorhandensein vertikaler Integration hindeutet.

Zum Beispiel:

• Nodereal hat einen Anteil von 100 % mit TWStaking.
• Bloxroute hat einen Anteil von 100 % mit Figment.
• 48Club hält über 90 % der Anteile mit Turing, The48Club, Shannon, Lista, Feynman und Avengers.

Die potenziellen Risiken, die sich aus dieser vertikalen Integration ergeben, unterscheiden sich von der auf Ethereum üblicheren Searcher-Builder-Integration. Insbesondere kann der Builder-Validator-Integrationsmechanismus ausgenutzt werden, um den Transaktionsfluss zu steuern, indem Transaktionen nur an bestimmte Validatoren übermittelt werden. Dies könnte zu Verlusten für die Nutzerinteressen führen und die Zentralisierungsrisiken verschärfen, was die Sicherheit der BNB Smart Chain direkt beeinträchtigt.

Risiken des 0 Gwei Transaktionsmechanismus

Der 0 Gwei Transaktionsmechanismus reduziert zwar die Kosten, schafft aber Möglichkeiten für die Ausnutzung 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. Anfangs nutzten diese Verträge den 0 Gwei-Transaktionsdienst von 48Club, indem sie Koge besaßen. Obwohl 48Club bestimmte Einschränkungen eingeführt hat, beobachten wir zum Zeitpunkt der Erstellung dieses Dokuments immer noch mehrere Phishing-Aktivitäten, die über den 0 Gwei-Transaktionsdienst von 48Club durchgeführt werden und eine erhebliche Bedrohung für die Sicherheit von BSC darstellen.

MEV-Angriffe werden immer häufiger, insbesondere Sandwich-Angriffe

Der aktuelle BSC PBS-Mechanismus hat den MEV-Angriffsmarkt neu gestaltet, wodurch es für Benutzer unerlässlich ist, die MEV-Schutzstrategien unter dieser neuen Struktur zu verstehen. Unter den verschiedenen MEV-Angriffen ist der Sandwich-Angriff einer der berüchtigtsten auf der Blockchain.

So funktioniert ein Sandwich-Angriff:

1. Ü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. ETH gegen USDT auf einer DEX tauschen).
2. Front-Running der Zieltransaktion: Der Angreifer sendet eine Transaktion vor der Zieltransaktion (Front-Running), um den Marktpreis zu beeinflussen. Zum Beispiel kauft der Angreifer den Ziel-Token, was seinen Preis in die Höhe treibt.
3. 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. Dies ermöglicht es dem Angreifer, von den Preisschwankungen zu profitieren, die durch die Zieltransaktion verursacht werden.

Für weitere Informationen zu MEV lesen Sie unsere detaillierte Analyse: Erntung von MEV-Bots durch Ausnutzung von Schwachstellen im Flashbots Relay.

Vor der Implementierung von PBS waren Transaktionen im öffentlichen Transaktionspool vollständig sichtbar und somit für Angreifer erkennbar. Angreifer konnten alle profitablen Transaktionen analysieren und die Transaktionsreihenfolge durch Kontrolle des Gaspreises manipulieren, was ihnen ermöglichte, Angriffe durchzuführen.

Der BSC PBS-Mechanismus führt einen privaten Kanal für Transaktionen ein, der es Benutzern ermöglicht, ihre Transaktionen an einen privaten Transaktionspool zu senden, der nur für Builder sichtbar ist. Dies stellt sicher, dass Transaktionen vor Angreifern verborgen bleiben (es sei denn, ein Builder gibt sie absichtlich preis) und bietet eine Schicht des MEV-Schutzes für Benutzer-Transaktionen.

Wir beobachteten, dass ein führender Sandwich-Bot (0x00000000004e660d7929B04626BbF28CBECCe534), der zuvor durch Kontrolle von Gaspreisen Sandwich-Angriffe durchführte, seit über 100 Tagen komplett seine Tätigkeit eingestellt hat. Dies deutet darauf hin, dass der PBS-Mechanismus auf BSC die Landschaft der MEV-Angriffe neu geordnet hat.

Durch die Beobachtung des On-Chain-Verhaltens und die Analyse statistischer Daten (z. B. Dune Analytics) haben wir jedoch festgestellt, dass nach der Implementierung von PBS (Mai 2024) die Anzahl der Sandwich-Angriffstransaktionen in der BSC-Kette erheblich zugenommen hat. Dieser scheinbare Widerspruch unterstreicht eine kritische Lücke in den aktuellen MEV-Schutzstrategien auf BSC.

Der Hauptgrund für den Anstieg der Sandwich-Angriffe ist, dass die meisten Händler und Projektteams die von PBS bereitgestellten privaten Kanäle nicht effektiv genutzt haben. Stattdessen senden sie weiterhin Transaktionen an den öffentlichen Transaktionspool. Für Angreifer sind die Kosten für die Erzielung von Angriffsmöglichkeiten nicht erheblich gestiegen.

Im Gegenteil, Angreifer nutzen die Fähigkeit des Builders, Bundles zu akzeptieren, indem sie sowohl die Zieltransaktion als auch die Angriffstransaktion in einem einzigen Bundle zusammenfassen, das dem Builder übermittelt wird. Wenn das Bundle erfolgreich in die Kette aufgenommen wird, ist der Sandwich-Angriff erfolgreich. Wenn es fehlschlägt, entstehen für den Sucher keine Verluste. Dies macht Sandwich-Angriffe kostengünstiger und effizienter und unterstreicht die Notwendigkeit eines robusten MEV-Schutzes.