Die BNB Smart Chain hat Anfang 2024 BEP 322 (den Proposer-Builder Separation-Mechanismus, oder PBS) implementiert, was zur Entstehung des BSC Builder-Marktes und zu neuen Ökosystemdynamiken geführt hat. Als Sicherheitsunternehmen beobachten wir die Entwicklung der BSC kontinuierlich, analysieren potenzielle derivierte Risiken durch die Untersuchung des PBS-Mechanismus und seines abgeleiteten Ökosystems und geben entsprechende Empfehlungen zur Risikominderung.
BSC-Validatoren haben einen erheblichen Einfluss innerhalb des BSC-Ökosystems. Die Eintrittsschwelle für BSC-Validatoren ist hoch, und die Anzahl der Validatoren wird konstant bei etwa 40-50 gehalten. Im Vergleich zu den Millionen von Validator-Knoten von Ethereum üben BSC-Validatoren einen stärkeren Einfluss auf das On-Chain-Ökosystem aus.
Nach Monaten intensiven Wettbewerbs hat der Builder-Markt eine stabile Struktur gebildet. Führende Akteure auf dem Builder-Markt, wie Blockrazor und 48Club-pussaint, tragen fast 80% des Blockaufbaus bei, während Bloxroute, Blocksmith und Nodereal zusammen etwa 19% ausmachen. Akteure am Ende der Rangliste tragen nur sporadisch zum Blockaufbau bei. Darüber hinaus haben wir diskutiert, dass das Phänomen der vertikalen Integration zwischen Validatoren und Buildern auf der BSC-Kette die Zentralisierungsrisiken weiter verschärfen könnte.
Der neue Mechanismus hat auch On-Chain-Transaktionsrisiken eingeführt, was zur Entstehung von Risikopräventionsprodukten geführt hat. Der einzigartige 0 Gwei-Transaktionsmechanismus der BSC reduziert die Transaktionskosten, hat aber zu häufigen Phishing-Aktivitäten on-chain geführt. Unter dem PBS-Mechanismus hat der Prozess des Builders, Transaktionsbündel zu empfangen, die Kosten für Sandwich-Angriffe gesenkt und Transaktionen anfälliger für solche Angriffe gemacht. Dies wiederum hat die Entwicklung von privaten RPC-Produkten zur Eindämmung von MEV (Maximum Extractable Value) vorangetrieben.
Unterschiede zwischen den PBS-Mechanismen von BSC und Ethereum
Ein guter Vergleichspunkt für den BSC-PBS-Mechanismus ist Ethereum. BSC hat die meisten Implementierungsprinzipien von Ethereum übernommen, aber es gibt immer noch einige detaillierte Unterschiede, wie z. B. Konsensmechanismen und die Topologie des Validator-Netzwerks:
① Eliminierung des Relay-Mechanismus:
Da die Anzahl der Validatoren auf BSC relativ gering ist, besteht keine Notwendigkeit für ein zentralisiertes Relay, um die Kommunikationskomplexität zwischen Buildern und Validatoren zu reduzieren. Darüber hinaus würde bei den kürzeren Blockintervallen von BSC die Verwendung eines Relays zur Weiterleitung von Transaktionen stattdessen die Kommunikationsverbindungen zwischen Buildern und Validatoren erhöhen und somit die Interaktionszeit verlängern.
Als Ergänzung zum Relay hat BSC den mev-sentry-Dienst eingeführt, bei dem jeder Validator seinen eigenen Sentry betreibt. Der Sentry-Dienst interagiert direkt mit den Buildern, und dieser Trennungsmechanismus zwischen Sentry und Validator bietet besseren Schutz für die Validatoren. Im Gegensatz zum Relay können Validatoren direkt Blockinhalte von Builder-Geboten über den Sentry erhalten, was es ihnen ermöglicht, die Gültigkeit von Builder-Geboten unabhängig zu überprüfen. Dies schützt die Interessen der Validatoren weiter. Während jedes Blockintervalls dürfen Builder nicht mehr als drei Gebote an den Sentry senden. Diese Beschränkung führt zu erheblichen Unterschieden in den Bietstrategien zwischen BSC-Buildern und Ethereum-Buildern.
② Unterschiede bei den Coinbase-Transfer-Einstellungen:
Im PBS-Mechanismus von Ethereum dürfen Builder die Coinbase-Adresse in ihre eigene ändern, was es Ethereum ermöglicht, Prioritätsgebühren von den Buildern ausführen und umverteilen zu lassen. Der PBS-Mechanismus von BSC hat diese Fähigkeit jedoch nicht, was die Flexibilität der Gebote und Zuweisungen der Builder etwas einschränkt.
③ Unterstützung für 0 Gwei-Transaktionen:
Vor dem BEP-322-Upgrade wurde der 0 Gwei-Mechanismus zuerst von 48Club als Mitgliedschaftsmerkmal eingeführt. Mitglieder, die eine bestimmte Menge von 48Clubs Token, KOGE, besaßen, konnten diese Funktion nutzen, die als spezieller Dienst von Validatoren 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 gesetzt, was bedeutet, dass Transaktionen mit einem Gaspreis von 0 zulässig sind. Um dies als Mindestgebührenschutz zu ergänzen, hat BSC eine Einschränkung festgelegt, dass der effektive Gaspreis eines Blocks nicht unter 1 fallen darf. Dieser einzigartige Mechanismus ermöglicht es Buildern, 0 Gwei-Transaktionen beim Aufbau von Blöcken einzuschließen, was eine effizientere Nutzung des Blockraums ermöglicht.
Entwicklung des Builder-Marktes
Ähnlich wie bei Ethereum entstand nach der Implementierung von PBS der Builder-Markt auf BSC und durchlief eine Entwicklungsphase, die schließlich zu einer stabilen ****Struktur führte.
Laut Statistiken von Dune haben insgesamt 8 Builder-Akteure 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. In der Zwischenzeit sind Bloxroute, Blocksmith und Nodereal zu 'Tier 2'-Akteuren geworden, während Jetbldr, Blockbus und Darwin nur sporadisch zur Blockproduktion beitragen.
Entwicklung von Validatoren
Im Gegensatz zu Ethereum bleibt die Anzahl der Validatoren auf BSC aufgrund der unterschiedlichen Eintrittsschwellen in einem stabilen Bereich. Auf Ethereum kann jeder Validator werden, indem er 32 ETH stakt, was zu über 1 Million Validatoren führt. Ethereum-Validatoren integrieren sich mit Relays, um sich mit Buildern zu verbinden, Blockvorschläge zu erhalten und die Blockproduktion abzuschließen.
Auf BSC ist für die Ernennung zum Validator jedoch das Staking einer großen Menge BNB erforderlich, 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 sind. Laut Statistiken von BSCScan staken diese 45 Validatoren zusammen 29.244.219 BNB (Stand 18. Dezember 2024), wobei der Validator mit dem geringsten Stake immer noch 73.446 BNB stakt.
Dieser Unterschied in der Validator-Konzentration hat bis zu einem gewissen Grad zu ökologischen Unterschieden zwischen BSC und Ethereum geführt. So entfällt auf BSC beispielsweise der geringere Kostenaufwand für die Verknüpfung von Buildern und Validatoren, was den Markt für Relay-Dienste eliminiert. Gleichzeitig bedeutet der hohe Einfluss der Validatoren, dass die Entwicklung des On-Chain-Ökosystems den Interessen der Validatoren Priorität einräumen muss. Dies kann sich auf die Wettbewerbsfähigkeit und den Enthusiasmus anderer Projektteams innerhalb des kollaborativen Ökosystems der öffentlichen Kette auswirken, abgesehen von den Validator-Gruppen.
Potenzielle On-Chain-Risiken
Vertikale Integration von Builder und Validator
Auf BSC gibt es ein signifikantes Phänomen der vertikalen Integration von Builder und Validator. Wir haben die Verteilung von von Buildern produzierten Blöcken über alle Validatoren im Zeitraum vom 1. Dezember, 00:00:00 (UTC) bis 18. Dezember, 00:00:00 (UTC) analysiert. Die Daten zeigen, dass einige Validator-Knoten Blockproduktionsstatistiken aufweisen, die erheblich vom Marktdurchschnitt abweichen, was auf die Existenz einer vertikalen Integration zwischen Buildern und Validatoren hinweist.
Beispielsweise:
- 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 Sucher-Builder-Integration. Insbesondere kann der Builder-Validator-Integrationsmechanismus ausgenutzt werden, um den Transaktionsfluss zu kontrollieren und Transaktionen nur an bestimmte Validatoren weiterzuleiten. Dies könnte zu Verlusten für Nutzerinteressen und einer Verschärfung der Zentralisierungsrisiken führen.
Risiken des 0 Gwei-Transaktionsmechanismus
Der 0 Gwei-Transaktionsmechanismus schafft Möglichkeiten für die Ausnutzung durch Phishing-Verträge. Mit 0 Gwei-Transaktionen können Phishing-Verträge Transaktionen kostenlos übertragen, was die Verbreitung von Phishing-Angriffen verschärft.
Auf BSC haben wir bereits mehrere Phishing-Verträge erkannt, die 0 Gwei-Transaktionen nutzen. Anfangs nutzten diese Verträge den 0 Gwei-Transaktionsdienst von 48Club durch den Besitz von Koge. Obwohl 48Club bestimmte Einschränkungen eingeführt hat, beobachten wir zum Zeitpunkt der Erstellung dieses Berichts immer noch mehrere Phishing-Aktivitäten, die über den 0 Gwei-Transaktionsdienst von 48Club durchgeführt werden.
MEV-Angriffe werden immer häufiger, insbesondere Sandwich-Angriffe
Der aktuelle PBS-Mechanismus hat den MEV-Angriffsmarkt neu geordnet, was es für Benutzer unerlässlich macht, MEV-Schutzstrategien unter dieser neuen Struktur zu verstehen. Unter den verschiedenen MEV-Angriffen ist der Sandwich-Angriff der berüchtigtste auf 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 Swap von ETH gegen USDT auf einem DEX).
-
Front-Running der Zieltransaktion:
Der Angreifer sendet eine Transaktion vor ****der Zieltransaktion (Front-Running), um den Marktpreis zu beeinflussen, bevor die Zieltransaktion ausgeführt wird. Zum Beispiel kauft der Angreifer den Zieltoken, wodurch dessen Preis steigt.
-
Back-Running der Zieltransaktion:
Nachdem die Zieltransaktion ausgeführt wurde, sendet der Angreifer eine weitere Transaktion nach ihr (Back-Running), um die im Front-Running-Schritt erworbenen Token zu verkaufen. Dadurch kann der Angreifer von den Preisschwankungen profitieren, die durch die Zieltransaktion verursacht werden.
Mehr Infos. zu MEV: https://blocksec.com/blog/harvesting-mev-bots-by-exploiting-vulnerabilities-in-flashbots-relay
Vor der Implementierung von PBS waren Transaktionen im öffentlichen Transaktionspool vollständig offengelegt und somit für Angreifer sichtbar. Angreifer konnten alle profitablen Transaktionen analysieren und die Reihenfolge der Transaktionen durch Steuerung des Gaspreises manipulieren, um Angriffe durchzuführen.
Der PBS-Mechanismus führt einen Datenschutzkanal 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 leakt sie absichtlich) und bietet Schutz für Benutzer-Transaktionen.
Wir haben beobachtet, dass ein führender Sandwich-Bot (0x00000000004e660d7929B04626BbF28CBECCe534), der zuvor Sandwich-Angriffe durch die Kontrolle von Gaspreisen durchgeführt hat, seit über 100 Tagen seinen Betrieb vollständig eingestellt hat. Dies deutet darauf hin, dass der PBS-Mechanismus auf BSC die MEV-Angriffslandschaft neu geordnet hat.
Durch die Beobachtung des On-Chain-Verhaltens und die Analyse von statistischen Daten (https://dune.com/hildobby/sandwiches?Blockchain_e8f77a=bnb) haben wir jedoch festgestellt, dass nach der Implementierung von PBS (Mai 2024) die Anzahl der Sandwich-Angriffstransaktionen auf der BSC-Kette erheblich zugenommen hat.
Der Hauptgrund für den Anstieg der Sandwich-Angriffe ist, dass die meisten Händler und Projektteams die von PBS bereitgestellten Datenschutzkanäle nicht effektiv nutzen. Stattdessen senden sie weiterhin Transaktionen an den öffentlichen Transaktionspool. Für Angreifer sind die Kosten für die Erlangung von Angriffsmöglichkeiten nicht erheblich gestiegen.
Im Gegenteil, Angreifer nutzen die Fähigkeit des Builders, Bündel zu akzeptieren, indem sie sowohl die Zieltransaktion als auch die Angriffstransaktion in ein einziges Bündel verpacken, das an den Builder übermittelt wird. Wenn das Bündel erfolgreich on-chain aufgenommen wird, gelingt der Sandwich-Angriff. Wenn es fehlschlägt, erleidet der Sucher keinen Verlust. Dies macht Sandwich-Angriffe kostengünstiger und effizienter.
Ein neuer Ansatz zur Bekämpfung von MEV-Angriffen
In der Post-PBS-Umgebung auf BSC, in der MEV-Angriffe immer häufiger und vielfältiger werden, sind neue Maßnahmen erforderlich, um diese Herausforderungen zu bewältigen.
Blocksec setzt sich dafür ein, Benutzern einen verbesserten Schutz für On-Chain-Aktivitäten zu bieten. In Zusammenarbeit mit BlockRazor, einem führenden Anbieter von Builder-Diensten auf BSC, haben wir eine MEV-geschützte RPC entwickelt.
Durch mehrere Testrunden hat diese RPC Folgendes bewiesen:
- 100%ige Wirksamkeit bei der Verhinderung von Sandwich- und Front-Running-Angriffen.
- Garantierte Transaktionsgeschwindigkeit, wobei 98% der Transaktionen im nächsten Block aufgenommen werden.
Dies schafft eine sicherere Handelsumgebung für Benutzer und verhindert Verluste durch Angriffe.
In Zukunft werden wir weiterhin mit BlockRazor zusammenarbeiten, um weitere Transaktionsdienstprogramme einzuführen und uns um eine sicherere und bessere On-Chain-Handelserfahrung zu bemühen.
Erfahren Sie, wie Sie RPC für sicheren Transaktionsschutz nutzen → https://docs.blocksec.com/blocksec-anti-mev-rpc
