Der Weg von BNB Chain zu den großen Blöcken

Die Straße der großen Blöcke auf der BNB-Kette

Ähnlich wie Solana, Heco und andere öffentliche Chains, die von Börsen unterstützt werden, verfolgt die öffentliche Chain BNB Smart Chain (BSC) von BNB Chain seit langem eine hohe Leistung. Seit seiner Einführung im Jahr 2020 hat BSC die Gaskapazitätsgrenze für jeden Block auf 30 Millionen festgelegt, mit einem stabilen Blockintervall von 3 Sekunden. Mit solchen Parametern erreichte BSC eine maximale TPS (TPS mit verschiedenen Transaktionen, die miteinander vermischt werden) von über 100. Im Juni 2021 wurde das Blockgaslimit von BSC auf 60 Millionen erhöht. Im Juli desselben Jahres explodierte jedoch ein Kettenspiel namens CryptoBlades auf BSC, was dazu führte, dass das tägliche Transaktionsvolumen 8 Millionen überstieg und die Gebühren in die Höhe schossen. Es stellte sich heraus, dass der Effizienzengpass von BSC zu diesem Zeitpunkt noch recht offensichtlich war.

(Quelle: BscScan)

Um die Probleme mit der Netzwerkleistung zu beheben, hob BSC das Gaslimit für jeden Block erneut an, das lange Zeit stabil bei etwa 80-85 Millionen blieb. Im September 2022 wurde das Gaslimit pro Block der BSC-Kette auf 120 Millionen erhöht, und bis Ende des Jahres wurde es auf 140 Millionen angehoben, fast das Fünffache von 2020. Zuvor hatte BSC geplant, die Blockgas-Kapazitätsgrenze auf 300 Millionen zu erhöhen, aber vielleicht in Anbetracht der hohen Belastung der Validator-Knoten wurde der Vorschlag für solche supergroßen Blöcke nicht umgesetzt.

Quelle: YCHARTS

Später schien sich BNB Chain mehr auf die Modular-/Layer2-Spur zu konzentrieren, als auf der Layer1-Erweiterung zu beharren. Diese Absicht wurde durch den Start von zkBNB in der zweiten Hälfte des vergangenen Jahres auf GreenField zu Beginn dieses Jahres immer deutlicher. Aufgrund eines starken Interesses an modularer Blockchain/Layer2 wird der Autor dieses Artikels opBNB als Forschungsobjekt verwenden, um die Leistungsengpässe von Rollup aufzudecken, indem er es mit Ethereum Layer2 vergleicht.

Der Schub des hohen Durchsatzes von BSC für die DA-Schicht von opBNB

Wie wir alle wissen, hat Celestia vier Schlüsselkomponenten nach dem Workflow der modularen Blockchain zusammengefasst: Execution Layer: Führt Vertragscode aus und schließt Zustandsübergänge ab; Abwicklungsschicht: Verarbeitet Betrugsnachweise/Gültigkeitsnachweise und behebt Überbrückungsprobleme zwischen L2 und L1. Konsensschicht: Erzielt einen Konsens über die Reihenfolge der Transaktionen. Data Availability Layer (DA): Veröffentlicht Blockchain-Ledger-bezogene Daten, sodass Validatoren diese Daten herunterladen können.

Unter ihnen ist die DA-Schicht oft mit der Konsensschicht gekoppelt. Beispielsweise enthalten die Daten der DA des optimistischen Rollups einen Stapel von Transaktionssequenzen in L2-Blöcken. Wenn L2-Vollknoten DA-Daten abrufen, kennen sie die Reihenfolge jeder Transaktion in diesem Batch. (Aus diesem Grund glaubt die Ethereum-Community, dass die DA-Schicht und die Konsensschicht beim Layering von Rollup verwandt sind.)

Für Ethereum Layer2 ist jedoch der Datendurchsatz der DA-Schicht (Ethereum) zum größten Engpass geworden, der die Rollup-Leistung einschränkt. Dies liegt daran, dass der derzeitige Datendurchsatz von Ethereum zu gering ist, was Rollup dazu zwingt, seine TPS so weit wie möglich zu unterdrücken, um zu verhindern, dass das Ethereum-Mainnet nicht in der Lage ist, die von L2 generierten Daten zu tragen. Gleichzeitig führt der geringe Datendurchsatz dazu, dass sich eine große Anzahl von Transaktionsanweisungen innerhalb des Ethereum-Netzwerks in einem ausstehenden Zustand befindet, was dazu führt, dass die Gasgebühren auf ein extrem hohes Niveau gedrückt werden und die Kosten für die Datenveröffentlichung für Layer2 weiter steigen. Schließlich müssen viele Layer2-Netzwerke DA-Schichten außerhalb von Ethereum übernehmen, wie z. B. Celestia, und opBNB, das sich in der Nähe des Wassers befindet, hat sich dafür entschieden, den hohen Durchsatz von BSC direkt zu nutzen, um DA zu implementieren, um das Engpassproblem der Datenveröffentlichung zu lösen. Zum besseren Verständnis stellen wir die Methode der DA-Datenveröffentlichung für Rollup vor. Am Beispiel von Arbitrum sendet die Ethereum-Chain, die von der EOA-Adresse des Layer2-Sequenzers kontrolliert wird, regelmäßig Transaktionen an den angegebenen Vertrag. In den Eingabeparametern calldata dieser Anweisung werden die gepackten Transaktionsdaten geschrieben und die entsprechenden On-Chain-Ereignisse ausgelöst, wodurch ein dauerhafter Datensatz in den Vertragsprotokollen verbleibt.

Auf diese Weise werden die Transaktionsdaten von Layer2 für eine lange Zeit in Ethereum-Blöcken gespeichert. Personen, die in der Lage sind, L2-Nodes zu betreiben, können die entsprechenden Datensätze herunterladen und die entsprechenden Daten analysieren, aber Ethereum-Nodes selbst führen diese L2-Transaktionen nicht aus. Es ist leicht zu erkennen, dass L2 nur Transaktionsdaten in Ethereum-Blöcken speichert, wodurch Speicherkosten anfallen, während die Rechenkosten für die Ausführung von Transaktionen von L2-Knoten selbst getragen werden. Dies ist die Implementierungsmethode von Arbitrums DA, während Optimism eine EOA-Adresse verwendet, die vom Sequenzer gesteuert wird, um an eine andere spezifizierte EOA-Adresse zu übertragen und einen neuen Stapel von Layer2-Transaktionsdaten in den zusätzlichen Daten zu tragen. Was opBNB betrifft, das den OP Stack verwendet, ist seine DA-Datenveröffentlichungsmethode im Grunde die gleiche wie die von Optimism.

Es liegt auf der Hand, dass der Durchsatz der DA-Schicht die Größe der Daten begrenzt, die Rollup in einer Zeiteinheit veröffentlichen kann, wodurch TPS eingeschränkt wird. Wenn man bedenkt, dass sich nach EIP1559 die Gaskapazität jedes ETH-Blocks bei 30 Millionen stabilisiert und die Blockzeit nach dem Merge etwa 12 Sekunden beträgt, kann Ethereum maximal nur 2,5 Millionen Gas pro Sekunde verarbeiten. In den meisten Fällen beträgt der Gasverbrauch für die Unterbringung von L2-Transaktionsdaten pro Byte in Calldata 16, sodass Ethereum eine maximale Anrufdatengröße von nur 150 KB pro Sekunde verarbeiten kann. Im Gegensatz dazu beträgt die maximale durchschnittliche Größe der pro Sekunde verarbeiteten Anrufdaten etwa 2910 KB, was dem 18,6-fachen der von Ethereum entspricht. Der Unterschied zwischen den beiden DA-Schichten ist offensichtlich.

Zusammenfassend lässt sich sagen, dass Ethereum etwa 150 KB L2-Transaktionsdaten pro Sekunde übertragen kann. Auch nach dem Start von EIP 4844 wird sich an dieser Zahl nicht viel ändern, sondern nur die DA-Gebühr sinken. Wie viele Transaktionsdaten können also in etwa 150 KB pro Sekunde enthalten sein? Hier müssen wir die Datenkomprimierungsrate von Rollup erklären. Vitalik war im Jahr 2021 zu optimistisch und schätzte, dass Optimistic Rollup die Größe der Transaktionsdaten auf 11 % der ursprünglichen Größe komprimieren kann. Zum Beispiel kann ein einfacher ETH-Transfer, der ursprünglich eine Calldata-Größe von 112 Byte belegte, durch Optimistic Rollup auf 12 Byte komprimiert werden, ERC-20-Transfers können auf 16 Byte komprimiert werden und Swap-Transaktionen auf Uniswap können auf 14 Byte komprimiert werden. Nach seiner Schätzung kann Ethereum etwa 10.000 L2-Transaktionen pro Sekunde aufzeichnen (mit verschiedenen Typen, die miteinander vermischt sind). Laut den vom Optimism-Team im Jahr 2022 veröffentlichten Daten kann die tatsächliche Datenkomprimierungsrate jedoch nur ein Maximum von etwa 37 % erreichen, was 3,5-mal niedriger ist als Vitaliks Schätzung.

(Vitaliks Schätzung des Rollup-Skalierbarkeitseffekts weicht deutlich von den tatsächlichen Bedingungen ab)

(Tatsächliche Komprimierungsraten, die durch verschiedene Kompressionsalgorithmen erreicht werden, die von Optimism offengelegt werden)

Geben wir also eine vernünftige Zahl an: Selbst wenn Ethereum sein Durchsatzlimit erreicht, liegt die maximale TPS aller Optimistic Rollups zusammen nur bei etwas über 2000. Mit anderen Worten, wenn Ethereum-Blöcke vollständig verwendet würden, um die von Optimistic Rollups veröffentlichten Daten zu übertragen, wie z. B. diejenigen, die auf Arbitrum, Optimism, Base und Boba verteilt sind, würde die kombinierte TPS dieser Optimistic Rollups nicht einmal 3000 erreichen, selbst unter den effizientesten Komprimierungsalgorithmen. Darüber hinaus müssen wir berücksichtigen, dass nach EIP1559 die Gaskapazität jedes Blocks durchschnittlich nur 50% des Maximalwerts beträgt, so dass die oben genannte Zahl halbiert werden sollte. Nach dem Start von EIP4844 werden die Transaktionsgebühren für die Veröffentlichung von Daten zwar deutlich gesenkt, aber die maximale Blockgröße von Ethereum wird sich nicht wesentlich ändern (da zu viele Änderungen die Sicherheit der ETH-Hauptkette beeinträchtigen würden), so dass der oben geschätzte Wert nicht viel voranschreiten wird.

Laut Daten von Arbiscan und Etherscan enthält ein Stapel von Transaktionen auf Arbitrum 1115 Transaktionen, die 1,81 Millionen Gas auf Ethereum verbrauchen. Wenn die DA-Schicht in jedem Block gefüllt ist, liegt die theoretische TPS-Grenze von Arbitrum bei etwa 1500. In Anbetracht des Problems der Reorganisation von L1-Blöcken kann Arbitrum natürlich keine Transaktionsbatches für jeden Ethereum-Block veröffentlichen, so dass die oben genannten Zahlen derzeit nur theoretisch sind. Darüber hinaus wird sich das DA-Problem mit der weit verbreiteten Einführung von Smart Wallets im Zusammenhang mit EIP 4337 noch verschärfen. Denn mit der Unterstützung von EIP 4337 kann die Art und Weise, wie Benutzer ihre Identität verifizieren, angepasst werden, z. B. das Hochladen von Binärdaten von Fingerabdrücken oder Iris, wodurch die Datengröße für reguläre Transaktionen weiter erhöht wird. Daher ist der geringe Datendurchsatz von Ethereum der größte Engpass, der die Rollup-Effizienz einschränkt, und dieses Problem kann für eine lange Zeit nicht richtig gelöst werden. Auf der anderen Seite beträgt in der BNB-Chain der öffentlichen BSC-Chain die maximale durchschnittliche Größe der pro Sekunde verarbeiteten Anrufdaten etwa 2910 KB, was dem 18,6-fachen der von Ethereum entspricht. Mit anderen Worten: Solange die Ausführungsschicht mithalten kann, kann die theoretische TPS-Obergrenze von Layer2 innerhalb des BNB-Chain-Ökosystems etwa das 18-fache von ARB oder OP erreichen. Diese Zahl wird auf der Grundlage der maximalen Blockgaskapazität der aktuellen BNB-Chain von 140 Millionen mit einer Blockzeit von 3 Sekunden berechnet.

Mit anderen Worten, das derzeitige aggregierte TPS-Limit aller Rollups innerhalb des BNB-Chain-Ökosystems ist 18,6-mal so hoch wie das von Ethereum (selbst wenn man ZKRollup berücksichtigt). Aus dieser Perspektive ist es leicht zu verstehen, warum so viele Layer2-Projekte die DA-Schicht unter der Ethereum-Chain verwenden, um Daten zu veröffentlichen, da der Unterschied ziemlich offensichtlich ist. Das Problem ist jedoch nicht so einfach. Neben dem Problem des Datendurchsatzes kann sich auch die Stabilität von Layer1 selbst auf Layer2 auswirken. Zum Beispiel warten die meisten Rollups oft mehrere Minuten, bevor sie einen Stapel von Transaktionen auf Ethereum veröffentlichen, da die Möglichkeit einer Reorganisation des Layer1-Blocks in Betracht gezogen wird. Wenn ein Layer1-Block reorganisiert wird, wirkt sich dies auf das Blockchain-Ledger von Layer2 aus. Daher wartet der Sequencer nach jeder Veröffentlichung eines L2-Transaktionsbatches auf die Veröffentlichung mehrerer neuer Layer1-Blöcke, wodurch die Wahrscheinlichkeit eines Blockrollbacks erheblich reduziert wird, bevor der nächste L2-Transaktionsbatch veröffentlicht wird. Dies verzögert die Zeit, in der L2-Blöcke endgültig bestätigt werden, und reduziert die Bestätigungsgeschwindigkeit großer Transaktionen (große Transaktionen erfordern irreversible Ergebnisse, um die Sicherheit zu gewährleisten). Zusammenfassend lässt sich sagen, dass Transaktionen, die in L2 auftreten, erst dann irreversibel werden, wenn sie in den DA-Layer-Blöcken veröffentlicht wurden und nachdem die DA-Schicht eine bestimmte Anzahl neuer Blöcke erzeugt hat. Dies ist ein wichtiger Grund, der die Rollupleistung einschränkt. Ethereum hat jedoch eine langsame Blockgenerierungsgeschwindigkeit und benötigt 12 Sekunden, um einen Block zu erstellen. Unter der Annahme, dass Rollup alle 15 Blöcke einen Stapel von L2-Transaktionen veröffentlicht, gibt es ein 3-Minuten-Intervall zwischen den verschiedenen Batches, und nach der Veröffentlichung jedes Batches muss immer noch gewartet werden, bis mehrere Layer1-Blöcke generiert wurden, bevor sie irreversibel werden (vorausgesetzt, sie werden nicht in Frage gestellt). Offensichtlich ist die Zeit von der Initiierung bis zur Irreversibilität von Transaktionen auf Ethereums Layer2 ziemlich lang, was zu einer langsamen Abwicklungsgeschwindigkeit führt. BNB Chain hingegen benötigt nur 3 Sekunden, um einen Block zu produzieren, und die Blöcke werden in nur 45 Sekunden irreversibel (die Zeit, die benötigt wird, um 15 neue Blöcke zu produzieren). Basierend auf den aktuellen Parametern, unter der Annahme der gleichen Anzahl von L2-Transaktionen und unter Berücksichtigung der Irreversibilität von L1-Blöcken, kann die Anzahl der Veröffentlichungen von Transaktionsdaten durch opBNB in einer Zeiteinheit bis zum 8,53-fachen der von Arbitrum betragen (einmal alle 45 Sekunden für erstere und einmal alle 6,4 Minuten für letztere). Es ist klar, dass die Abwicklungsgeschwindigkeit großer Transaktionen auf opBNB viel schneller ist als auf Ethereums Layer2. Darüber hinaus kann die maximale Datengröße, die von opBNB jedes Mal veröffentlicht wird, das 4,66-fache der von Ethereums Layer2 erreichen (das L1-Blockgas-Limit des ersteren liegt bei 140 Millionen, während das des letzteren bei 30 Millionen liegt). 8,53 * 4,66 = 39,74. Dies stellt die Lücke zwischen opBNB und Arbitrum in Bezug auf das TPS-Limit in der praktischen Umsetzung dar (derzeit scheint ARB aus Sicherheitsgründen TPS aktiv zu reduzieren, aber theoretisch, wenn TPS erhöht würde, wäre es im Vergleich zu opBNB immer noch um ein Vielfaches niedriger).

(Der Sequenzer von Arbitrum veröffentlicht alle 6-7 Minuten einen Transaktions-Batch)

(Der Sequenzer von opBNB veröffentlicht alle 1-2 Minuten einen Transaktions-Batch, wobei der schnellste nur 45 Sekunden dauert). Natürlich gibt es noch einen weiteren entscheidenden Punkt zu beachten, nämlich die Gasgebühren in der DA-Schicht. Jedes Mal, wenn L2 einen Transaktionsbatch veröffentlicht, fallen Fixkosten von 21.000 Gas an, die nicht mit der Größe der Anrufdaten zusammenhängen, d. h. ein Aufwand. Wenn die Gasgebühren für die DA-Schicht/L1 hoch sind und die Fixkosten für die Veröffentlichung eines Transaktionsbatches auf L2 hoch bleiben, reduziert der Sequencer die Häufigkeit der Veröffentlichung von Transaktionsbatches. Darüber hinaus sind die Kosten der Ausführungsschicht bei der Betrachtung der Komponenten der L2-Gebühren sehr niedrig und können oft ignoriert werden, wobei der Schwerpunkt nur auf den Auswirkungen der DA-Kosten auf die Transaktionsgebühren liegt. Zusammenfassend lässt sich sagen, dass die Veröffentlichung von Anrufdaten gleicher Größe zwar die gleiche Menge an Gas auf Ethereum und BNB Chain verbraucht, der von Ethereum berechnete Gaspreis jedoch etwa 10 bis Dutzende Male höher ist als der von BNB Chain. Übersetzt in L2-Transaktionsgebühren sind die aktuellen Transaktionsgebühren der Nutzer auf Ethereum Layer2 auch etwa 10 bis dutzende Male höher als die auf opBNB. Insgesamt sind die Unterschiede zwischen opBNB und Optimistic Rollup auf Ethereum ziemlich offensichtlich.

(Eine Transaktion, die 150.000 Gas verbraucht, kostet 0,21 US-Dollar)

(Eine Transaktion, die 130.000 Gas auf opBNB verbraucht, kostet 0,004 USD) Die Erhöhung des Datendurchsatzes der DA-Schicht kann zwar den Gesamtdurchsatz des Layer2-Systems erhöhen, hat jedoch immer noch begrenzte Auswirkungen auf die Leistungsverbesserung einzelner Rollups. Dies liegt daran, dass die Ausführungsschicht Transaktionen oft nicht schnell genug verarbeitet. Auch wenn die Einschränkungen der DA-Schicht ignoriert werden können, wird die Ausführungsschicht zum nächsten Engpass, der sich auf die Rollup-Leistung auswirkt. Wenn die Ausführungsgeschwindigkeit der Layer2-Ausführungsschicht langsam ist, breitet sich der Überlauf der Transaktionsnachfrage auf andere Layer2s aus, was letztendlich zu einer Fragmentierung der Liquidität führt. Daher ist auch die Verbesserung der Leistung der Ausführungsschicht von entscheidender Bedeutung, die als weitere Schwelle über der DA-Schicht dient.

opBNB's Boost in der Ausführungsschicht: Cache-Optimierung

Wenn die meisten Leute über die Leistungsengpässe von Blockchain-Ausführungsschichten diskutieren, erwähnen sie unweigerlich zwei wichtige Engpässe: die serielle Single-Thread-Ausführung des EVM, die die CPU nicht vollständig nutzt, und die ineffiziente Datensuche des von Ethereum übernommenen Merkle Patricia Trie. Im Kern geht es bei den Skalierungsstrategien für die Ausführungsschicht darum, CPU-Ressourcen effizienter zu nutzen und sicherzustellen, dass die CPU schnellstmöglich auf Daten zugreifen kann.

Optimierungslösungen für die serielle EVM-Ausführung und Merkle Patricia Trie sind oft komplex und schwierig zu implementieren, während sich die kostengünstigeren Bemühungen in der Regel auf die Cache-Optimierung konzentrieren. Tatsächlich bringt uns die Cache-Optimierung zurück zu Punkten, die häufig im traditionellen Web2 und sogar in Lehrbüchern diskutiert werden.

In der Regel ist die Geschwindigkeit, mit der die CPU Daten aus dem Arbeitsspeicher abruft, hundertmal schneller als das Abrufen von Daten von der Festplatte. Beispielsweise kann das Abrufen von Daten aus dem Arbeitsspeicher nur 0,1 Sekunden dauern, während das Abrufen von der Festplatte 10 Sekunden dauern kann. Daher wird die Reduzierung des durch Lese- und Schreibvorgänge auf der Festplatte erzeugten Overheads, d. h. die Cache-Optimierung, zu einem wesentlichen Aspekt der Optimierung der Blockchain-Ausführungsschicht.

Bei Ethereum und den meisten anderen öffentlichen Chains wird die Datenbank, die den On-Chain-Adressstatus aufzeichnet, vollständig auf der Festplatte gespeichert, während der sogenannte Weltzustand lediglich ein Index dieser Datenbank oder ein Verzeichnis ist, das für die Datensuche verwendet wird. Jedes Mal, wenn das EVM einen Vertrag ausführt, muss es auf relevante Adresszustände zugreifen. Das nacheinander abgerufene Daten aus der datenträgerbasierten Datenbank würde die Transaktionsausführung erheblich verlangsamen. Daher ist das Einrichten eines Caches außerhalb der Datenbank/Festplatte ein notwendiges Mittel zur Beschleunigung.

opBNB übernimmt direkt die von BNB Chain verwendete Cache-Optimierungslösung. Nach Informationen des opBNB-Partners NodeReal richtete die früheste BSC-Kette drei Cache-Schichten zwischen der EVM und der LevelDB-Datenbank ein, in der der Zustand gespeichert wird. Das Designkonzept ähnelt dem herkömmlicher dreistufiger Caches, bei denen Daten mit höherer Zugriffsfrequenz im Cache gespeichert werden. Dadurch kann die CPU zunächst im Cache nach den benötigten Daten suchen. Wenn die Cache-Trefferrate hoch genug ist, muss sich die CPU beim Abrufen von Daten nicht übermäßig auf den Datenträger verlassen, was zu einer deutlichen Verbesserung der Gesamtausführungsgeschwindigkeit führt.

Später fügte NodeReal darüber hinaus eine Funktion hinzu, die die ungenutzten CPU-Kerne nutzt, um die Daten, die das EVM in Zukunft verarbeiten muss, präventiv aus der Datenbank zu lesen und im Cache zu speichern. Diese Funktion wird als "State Preloading" bezeichnet.

Das Prinzip des Zustandsvorladens ist einfach: Die CPUs der Blockchain-Knoten sind Multi-Core, während die EVM in einem seriellen Single-Thread-Ausführungsmodus arbeitet und nur einen CPU-Kern verwendet, so dass andere CPU-Kerne nicht ausgelastet sind. Um dieses Problem zu beheben, können die CPU-Kerne, die nicht von der EVM verwendet werden, bei Aufgaben helfen, indem sie die Daten vorhersagen, die die EVM aus der noch zu verarbeitenden Transaktionssequenz benötigt. Diese CPU-Kerne außerhalb des EVM rufen dann die Daten ab, die das EVM aus der Datenbank benötigt, was dem EVM hilft, den Aufwand für den Datenabruf zu reduzieren und somit die Ausführung zu beschleunigen.

Mit Cache-Optimierung und ausreichenden Hardware-Konfigurationen hat opBNB die Leistung der Ausführungsschicht seines Knotens effektiv an die Grenze des EVM gebracht und bis zu 100 Millionen Gas pro Sekunde verarbeitet. Diese 100 Millionen Gas sind im Wesentlichen die Leistungsgrenze des unmodifizierten EVM, wie experimentelle Testdaten einer bekannten öffentlichen Kette zeigen.

Um es kurz und bündig auszudrücken, opBNB kann bis zu 4761 einfache Überweisungen pro Sekunde, 15003000 ERC20-Token-Transfers pro Sekunde und etwa 5001000 SWAP-Operationen pro Sekunde verarbeiten, basierend auf Transaktionsdaten, die auf Blockchain-Explorern beobachtet werden. Vergleicht man die aktuellen Parameter, so ist das TPS-Limit von opBNB 40-mal so hoch wie das von Ethereum, mehr als 2-mal so hoch wie das von BNB Chain und mehr als 6-mal so hoch wie das von Optimism.

Natürlich wird bei Ethereum Layer2-Lösungen aufgrund der starken Einschränkungen der DA-Schicht selbst die Leistung auf der Grundlage der Leistung der Ausführungsschicht erheblich reduziert, wenn Faktoren wie die Zeit und Stabilität des DA-Layer-Blocks berücksichtigt werden.

Für BNB Chain mit einer DA-Schicht mit hohem Durchsatz wie opBNB ist der Verdopplungseffekt der Skalierung wertvoll, insbesondere wenn man bedenkt, dass BNB Chain mehrere solcher Skalierungsprojekte hosten kann. Es ist absehbar, dass BNB Chain bereits opBNB-geführte Layer2-Lösungen in seine strategischen Pläne integriert hat und weitere modulare Blockchain-Projekte einbinden wird, einschließlich der Einführung von ZK-Beweisen in opBNB und der Bereitstellung hochverfügbarer DA-Schichten mit komplementärer Infrastruktur wie GreenField, um mit dem Ethereum-Layer2-Ökosystem zu konkurrieren oder mit ihm zu kooperieren.

In der Ära, in der die mehrschichtige Skalierung zum Trend geworden ist, bleibt abzuwarten, ob sich auch andere öffentliche Chains beeilen werden, ihre eigenen Layer2-Projekte zu unterstützen, aber zweifellos findet der Paradigmenwechsel hin zu einer modularen Blockchain-Infrastruktur bereits statt.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [极客 Web3], Alle Urheberrechte liegen beim ursprünglichen Autor [Faust, 极客web3]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.