Expansion war schon immer eines der Themen, an denen Ethereum nicht vorbeikommt. Wenn Ethereum ein echter „Weltcomputer“ werden will, muss es gleichzeitig skalierbar, sicher und dezentral sein In der Branche als „Unmögliches Dreieck der Blockchain“ bekannt, ist es ein großes Problem, das in der gesamten Branche nicht gelöst wurde.
Ende 2021 schlug der Ethereum-Forscher und -Entwickler Dankrad Feist jedoch Danksharding vor, eine neue Sharding-Lösung für Ethereum, die eine revolutionäre Lösung für das „unmögliche Dreieck der Blockchain“ gebracht zu haben scheint und möglicherweise sogar die gesamten Spielregeln der Branche neu schreibt .
In diesem Forschungsbericht wird versucht, in der Umgangssprache klar zu erklären, was die neue Sharding-Lösung Danksharding von Ethereum ist und welche Vor- und Nachteile sie hat. Der Grund, warum dieser Forschungsbericht geschrieben wurde, liegt darin, dass es nur sehr wenige chinesische Artikel über Danksharding gibt und die meisten von ihnen eine hohe Wissensschwelle erfordern. Daher wird Spinach versuchen, die komplexen Prinzipien hinter Danksharding für Sie aufzuschlüsseln und eine einfache Umgangssprache zu verwenden Ein Web3-Anfänger kann auch die neue Sharding-Lösung von Ethereum, Danksharding, und seine Front-End-Lösung, EIP-4844, verstehen.
Autor: Spinat Spinat
Wortzahl: Dieser Forschungsbericht umfasst mehr als 10.000 Wörter und die geschätzte Lesezeit beträgt 21 Minuten
Inhaltsverzeichnis
Warum muss Ethereum expandieren?
Hintergrund der Ethereum-Erweiterung
Was ist das unmögliche Dreieck der Blockchain?
Was sind die aktuellen Skalierungslösungen für Ethereum?
Die erste Sharding-Lösung von Ethereum Sharding1.0
Wie funktioniert der POS-Konsensmechanismus von Ethereum?
Wie sieht die erste Sharding-Lösung Sharding1.0 aus?
Was sind die Nachteile der anfänglichen Sharding-Lösung Sharding1.0?
Was ist Danksharding, die neue Sharding-Lösung von Ethereum?
Prototyp EIP-4844: Proto-Danksharding – Neuer Transaktionstyp Blob
Danksharding – komplette Erweiterungslösung
Datenverfügbarkeitsstichprobe
Löschcodierung
KZG-Polynom-Commitment (KZG-Commitment)
Trennung zwischen Antragsteller und Bauträger
Zensurwiderstandsliste (crList)
Neuer PBS (Zwei-Slot-Proposer-Builder-Trennung)
Zusammenfassen
Verweise
Warum muss Ethereum expandieren?
Nachdem Ethereum-Gründer Vitalik Buterin 2014 das Whitepaper „Next Generation Smart Contracts and Decentralized Application Platform“ von Ethereum veröffentlichte, läutete die Blockchain eine neue Ära ein. Die Geburt intelligenter Verträge ermöglicht es Menschen, dezentrale Anwendungen (DApps) auf Ethereum zu erstellen, und bringt auch eine Reihe von Innovationen in das Blockchain-Ökosystem wie NFT, DeFi, GameFi usw.
Hintergrund der Ethereum-Erweiterung
Während das Ökosystem in der Ethereum-Kette wächst, beginnen immer mehr Menschen, Ethereum zu nutzen, und die Leistungsprobleme von Ethereum werden sichtbar. Wenn viele Menschen gleichzeitig auf Ethereum interagieren, kommt es in der Blockchain zu „Stauungen“, genau wie die Ampelzeit auf einer Straße festgelegt ist und die Anzahl der Fahrzeuge innerhalb einer bestimmten Anzahl keinen Stau verursacht, sondern plötzlich während der Hauptverkehrszeit Wenn die Ampel auf Grün wechselt, fahren viele Autos auf die Straße. Die Zahl der Fahrzeuge, die bei Grün auf die Straße fahren, ist weitaus geringer als die Zahl der neuen Fahrzeuge, die auf die Ampel warten Die Zeit, die alle Fahrzeuge benötigen, um diese Straße zu passieren, wird für immer verlängert, und das Gleiche gilt für die Bestätigungszeit aller interaktiven Anfragen.
Aber in der Blockchain ist es nicht nur die Zeit, die gestreckt wird, sondern auch hohe Gasgebühren (Gasgebühren können als harte Gebühren verstanden werden, die an Miner gezahlt werden, die für die Verpackung und Verarbeitung aller Transaktionen in der Blockchain verantwortlich sind), weil Miner geben Priorität für Transaktionen mit den höchsten Geboten, was dazu führen wird, dass jeder die Gasgebühr erhöht, um für eine schnellere Bestätigung von Interaktionsanfragen zu kämpfen, was einen „Gaskrieg“ auslöst. Eines der bekannteren Ereignisse war ein NFT-Projekt im Jahr 2017 – CryptoKitties. Die Beliebtheit von CryptoKitties ließ die Gasgebühr auf Hunderte von Dollar pro Interaktion steigen.
Der Hauptgrund für solch teure Gasgebühren liegt darin, dass die Leistung von Ethereum den Interaktionsbedürfnissen bestehender Benutzer nicht mehr gerecht werden kann. In Bezug auf die Leistungsberechnung unterscheidet sich Ethereum von Bitcoin. Bitcoin verwendet nur ein einfaches Hauptbuch zur Verarbeitung von Übertragungsinformationen, daher ist TPS fest und kann 7 Transaktionen pro Sekunde verarbeiten, bei Ethereum ist es jedoch anders.
Aufgrund der Existenz intelligenter Verträge in Ethereum ist der Inhalt jeder Transaktion unterschiedlich. Wie viele Transaktionen (TPS) jeder Block verarbeiten kann, hängt also vom Datenvolumen der in einem Block enthaltenen Transaktionen und vom Datenvolumen jeder Transaktion ab. Die Größe wird basierend auf der Echtzeitnachfrage bestimmt. Wir können mehr über den Leistungsmechanismus von Ethereum erfahren: (Die folgenden Informationen sind hilfreich für das Verständnis von Danksharding, lesen Sie sie unbedingt.)
Ethereum legt die Obergrenze der Datenmenge eines Blocks basierend auf der Gasgebühr fest. Ein Block kann bis zu 30 Millionen GAS an Daten transportieren.
Ethereum möchte nicht, dass die Datenmenge in jedem Block zu groß wird, daher hat jeder Block ein Gasziel (Zielgas) von 15 Millionen Gas.
Ethereum verfügt über eine Reihe von Gasdatenverbrauchsstandards. Laut Spinachs Schätzung ist jeder Block jedoch etwa 5 KB bis 160 KB groß
Sobald der Gasverbrauch eines Blocks das Gasziel von 15 Millionen Gas überschreitet, wird die Grundgebühr des nächsten Blocks um 12,5 % teurer. Wenn sie niedriger als die Grundgebühr ist, wird die Grundgebühr gesenkt. Bei diesem Mechanismus handelt es sich um einen automatisierten dynamischen Anpassungsmechanismus, der die Kosten weiter erhöhen kann, um die Überlastung zu verringern, wenn die Transaktionen ihren Höhepunkt erreichen, und gleichzeitig die Kosten senkt, um mehr Transaktionen anzuziehen, wenn die Transaktionen schleppend sind.
Wenn wir dann den oben genannten Mechanismus verstehen, können wir erkennen, dass der TPS von Ethereum schwankt. **Wir können die ungefähre TPS berechnen, indem wir die Anzahl der Transaktionen in jedem Block über den Blockchain-Browser sehen. Wie aus der folgenden Abbildung ersichtlich ist, hat ein Block im Durchschnitt etwa 160 Transaktionen, basierend auf dem Erreichen des Gasziels Höchste kann mehr als 300 Transaktionen erreichen. Basierend auf der Blockgenerierungszeit von 12 Sekunden pro Block beträgt die TPS etwa 13 bis 30 Transaktionen, laut der derzeit bekannten TPS von Ethereum kann sie jedoch maximal 45 Transaktionen pro Sekunde erreichen.
Quelle: Mainnet | Beacon Chain Explorer (Phase 0) für Ethereum 2.0 – BeaconScan
Nehmen wir als Beispiel die Leistung des weltberühmten Handelssystems VISA, das Zehntausende Transaktionen pro Sekunde abwickeln kann, die Leistung von Ethereum, das ein „Weltcomputer“ werden will und bis zu 45 bewältigen kann Transaktionen pro Sekunde ist wirklich zu schwach. Daher muss Ethereum dringend erweitert werden, um Leistungsprobleme zu lösen, die mit der Zukunft von Ethereum zusammenhängen. Allerdings ist die Erweiterung keine leichte Aufgabe, da es in der Blockchain-Branche ein „unmögliches Dreieck“ gibt.
Was ist das unmögliche Dreieck der Blockchain?
„Blockchain Impossible Triangle“ bezieht sich auf die Tatsache, dass eine öffentliche Blockchain nicht drei Eigenschaften gleichzeitig erfüllen kann: Dezentralisierung, Sicherheit und Skalierbarkeit.
Dezentralisierung: bezieht sich auf den Grad der Dezentralisierung von Knoten. Je mehr Knoten es gibt, desto verteilter und dezentralisierter sind sie.
Sicherheit: bezieht sich auf die Sicherheit des gesamten Blockchain-Netzwerks. Je höher die Angriffskosten, desto sicherer.
Skalierbarkeit: bezieht sich auf die Transaktionsverarbeitungsleistung der Blockchain. Je mehr Transaktionen pro Sekunde verarbeitet werden können, desto skalierbarer ist sie.
Wenn wir die Bedeutung dieser drei Punkte betrachten, werden wir feststellen, dass Dezentralisierung und Sicherheit die Eckpfeiler von Ethereum sind. Es ist die Dezentralisierung, die Ethereum Neutralität, Zensurresistenz, Offenheit, Dateneigentum und nahezu unzerbrechliche Sicherheit verleiht . Die Bedeutung der Sicherheit muss natürlich nicht erklärt werden, aber die Vision von Ethereum besteht darin, Skalierbarkeit unter der Prämisse von Dezentralisierung und Sicherheit zu erreichen. Die Schwierigkeit der Umsetzung kann man sich vorstellen, daher wird dies auch als „Blockchain Impossible Triangle“ bezeichnet.
Bildquelle: Ethereum Vision |. ethereum.org
Was sind die aktuellen Skalierungslösungen für Ethereum?
Wir wissen, dass im „Unmöglichen Dreieck der Blockchain“ die Voraussetzung für eine Expansion von Ethereum darin bestehen muss, Dezentralisierung und Sicherheit zu gewährleisten. Die Fähigkeitsanforderungen für Knoten sollten nicht überschritten werden. Da Knoten eine unverzichtbare Rolle bei der Aufrechterhaltung des gesamten Ethereum-Netzwerks spielen, verhindern Knoten mit hohen Anforderungen, dass mehr Menschen zu Knoten werden und immer zentraler werden. Je niedriger der Schwellenwert für Knoten, desto besser Wenn mehr Menschen teilnehmen, wird Ethereum dezentraler und sicherer.
Daher gibt es derzeit zwei Erweiterungslösungen für Ethereum: Layer2 und Sharding. Layer2 ist eine Off-Chain-Lösung für die Erweiterung der zugrunde liegenden Blockchain (Layer1). Das Prinzip besteht darin, Anfragen in Off-Chain-Ausführung zu stellen. Es gibt mehrere Layer2-Lösungen. Dieser Forschungsbericht konzentriert sich nur auf eine Layer2-Lösung, nämlich Rollup: Das Prinzip von Rollup besteht darin, Hunderte von Transaktionen außerhalb der Kette wie Pfannkuchen in eine Transaktion zu packen und sie auf diese Weise an Ethereum zu senden Jeder kann sich sehr günstig an den Kosten für das Hochladen auf Ethereum beteiligen und gleichzeitig die Sicherheit von Ethereum erben.
Rollup wird derzeit in zwei Typen unterteilt: Optimismus-Rollup (optimistischer Rollup) und ZK-Rollup (wissensfreier Rollup). Der Unterschied zwischen diesen beiden Rollups geht einfach davon aus, dass alle Transaktionen ehrlich und vertrauenswürdig sind und an Ethereum übermittelt wird, gibt es nach der Übermittlung eine gewisse Zeit (Herausforderungsfrist – derzeit eine Woche). Jeder kann die Echtheit der Transaktion überprüfen und eine Herausforderung einleiten, wenn der Benutzer jedoch die ETH auf das OP übertragen möchte Rollup Wenn Sie zu Ethereum wechseln, müssen Sie das Ende des Challenge-Zeitraums abwarten, bevor Sie die endgültige Bestätigung erhalten.
ZK Rollup beweist, dass alle Transaktionen gültig sind, indem es einen wissensfreien Beweis erstellt und die endgültigen Statusänderungen nach der Ausführung aller Transaktionen auf Ethereum hochlädt. ZK Rollup ist vielversprechender als Optimism Rollup. Es müssen nicht alle komprimierten Transaktionsdetails hochgeladen werden. Es müssen nur wissensfreie Beweise und die endgültigen Statusänderungsdaten hochgeladen werden, was bedeutet, dass es komprimiert werden kann mehr Daten als OP Rollup, und es muss nicht wie bei OP Rollup auf eine einwöchige Herausforderungsphase gewartet werden. Der größte Nachteil von ZK Rollup besteht jedoch darin, dass es äußerst schwierig zu entwickeln ist, sodass Optimism Rollup dies kurzfristig tun wird besetzen einen großen Teil des L2-Marktes.
Zusätzlich zu Layer2 gibt es eine weitere Erweiterungslösung, nämlich Sharding, den Protagonisten dieses Artikels. Wir wissen, dass Layer2 Transaktionen auf Ethereum zur Verarbeitung bereitstellt. Unabhängig davon, wie Layer2 Daten verarbeitet, bleibt die Leistung von Ethereum selbst unverändert, sodass der Erweiterungseffekt, den Layer2 erzielen kann, eigentlich nicht so groß ist.
Beim Sharding geht es darum, eine Erweiterung auf der Ebene 1 von Ethereum zu erreichen. Wir wissen jedoch, dass die Voraussetzung für die Erweiterung auf Ethereum die Gewährleistung der Dezentralisierung und Sicherheit von Ethereum ist, sodass wir die Knoten nicht zu sehr belasten dürfen.
Das spezifische Implementierungsschema von Sharding war schon immer ein Thema ständiger Diskussionen in der Ethereum-Community. Das neueste Schema ist Danksharding, das Thema dieses Artikels. Bevor über Danksharding gesprochen wird, wird erwähnt Lassen Sie mich außerdem kurz vorstellen, wie die alte Sharding-Lösung aussieht und warum sie nicht übernommen wird.
Die erste Sharding-Lösung von Ethereum Sharding1.0
Bevor wir über die Sharding 1.0-Lösung sprechen, müssen wir zunächst die Funktionsweise des aktuellen POS-Konsensmechanismus von Ethereum vorstellen, da dies das notwendige Vorwissen zum Verständnis der Sharding 1.0-Lösung und Danksharding ist kurze Zusammenfassung (ich weiß nur ungefähr, was zu tun ist).
Wie funktioniert der POS-Konsensmechanismus von Ethereum? [7]
Der Konsensmechanismus ist ein System, das es allen Knoten, die das Netzwerk in der Blockchain aufrechterhalten, ermöglicht, einen Konsens zu erzielen, und seine Bedeutung liegt auf der Hand. Ethereum hat „The Merge“ in der Upgrade-Phase von Ethereum 2.0 am 15. September 2022 abgeschlossen, d Es ersetzte den POW-Workload-Proof-Mechanismus und wurde zum Konsensmechanismus von Ethereum.
Wir wissen, dass Miner im POW-Workload-Proof-Mechanismus um das Recht konkurrieren, Blöcke durch Stapeln von Rechenleistung zu produzieren. Im POS-Equity-Proof-Mechanismus konkurrieren Miner um das Recht, Blöcke zu produzieren, indem sie 32 ETH als Verifizierungsknoten verpflichten Ethereum. Blockrechte (die Absteckmethode wird hier nicht vorgestellt).
Zusätzlich zu den Änderungen im Konsensmechanismus hat sich auch die Blockzeit von Ethereum von der vorherigen Floating-Block-Zeit zu einer festen Zeit geändert, die in zwei Einheiten unterteilt ist: Slot (Slot) und Periode (Epoch): Slot beträgt 12 Sekunden und Epoche beträgt 6,4 Minuten. Eine Epoche enthält einfach 32 Slots, ein Block wird in 12 Sekunden produziert und 32 Blöcke werden in 6,4 Minuten als ein Zyklus (Epoche) produziert.
Wenn ein Miner 32 ETH zusagt, um ein Verifizierungsknoten zu werden, verwendet die Beacon-Kette einen Zufallsalgorithmus, um den Verifizierungsknoten als blockerzeugenden Knoten auszuwählen, um den Block zu verpacken. Jeder Block wählt zufällig einen blockerzeugenden Knoten aus. Gleichzeitig weist die Beacon-Kette in jedem Epochenzyklus alle Verifizierungsknoten gleichmäßig und zufällig jedem Block einer Gruppe von „Komitees“ zu, die aus mindestens 128 Verifizierungsknoten besteht.
Das heißt, jedem Block wird 1/32 der Anzahl der Verifizierungsknoten aller Knoten zugewiesen. Die aus diesen Verifizierungsknoten bestehenden „Komitees“ müssen die von den blockerzeugenden Knoten jedes Blocks gepackten Blöcke verifizieren und darüber abstimmen. Wenn der Block produzierende Knoten den Block verpackt, stimmen mehr als zwei Drittel der Verifizierungsknoten für die erfolgreiche Produktion des Blocks.
Wie sieht die erste Sharding-Lösung Sharding1.0 aus? [7]
Im Designkonzept der ersten Sharding-Lösung Sharding1.0 wurde Ethereum von der ursprünglichen Hauptkette auf maximal 64 Shard-Ketten entworfen, und die Erweiterung wurde durch das Hinzufügen mehrerer neuer Ketten erreicht. Bei dieser Lösung ist jede Shard-Kette für die Verarbeitung der Ethereum-Daten und deren Übergabe an die Beacon-Kette verantwortlich. Die Beacon-Kette ist für die Koordination des gesamten Ethereum verantwortlich. Die blockerzeugenden Knoten und Komitees jeder Shard-Kette werden vom Beacon gesteuert Kette. Ketten werden zufällig zugewiesen.
Die Beacon-Kette und die Shard-Kette sind über Querverbindungen miteinander verbunden. Der Block der Beacon-Kette gibt dem Shard-Block desselben Blocks einen Hash-Wert, und der Shard-Block überträgt diesen Hash dann an den nächsten Beacon-Block, Crosslinks können erreicht werden. Wenn der Wert fehlt, wird er an den nächsten Beacon-Block weitergegeben.
Was sind die Nachteile der anfänglichen Sharding-Lösung Sharding1.0?
Vereinfacht ausgedrückt besteht die Sharding-1.0-Lösung darin, Ethereum in viele Shard-Ketten aufzuteilen, um Daten gemeinsam zu verarbeiten, und die Daten dann an die Beacon-Kette zu übergeben, um eine Erweiterung zu erreichen. Diese Lösung hat jedoch viele Nachteile:
**Entwicklungsschwierigkeiten:** Es ist technisch sehr schwierig, Ethereum in 64 Shard-Ketten aufzuteilen und dabei den normalen Betrieb sicherzustellen, und je komplexer das System ist, desto wahrscheinlicher ist es, dass einige unvorhersehbare Lücken entstehen Ärger, wenn Probleme auftreten und repariert werden müssen.
**Datensynchronisationsproblem:** Jeder Epochenzyklus der Beacon-Kette wird die für die Verifizierung verantwortlichen „Komitees“ erneut stören, sodass jede Neuverteilung von Verifizierungsknoten eine Datensynchronisation eines großen Netzwerks darstellt, denn wenn dies der Fall ist Wenn a Wird dem Knoten eine neue Shard-Kette zugewiesen, muss er die Daten dieser Shard-Kette synchronisieren. Aufgrund der unterschiedlichen Leistungsbandbreiten der Knoten ist es schwierig sicherzustellen, dass die Synchronisierung innerhalb der angegebenen Zeit abgeschlossen wird. Wenn Knoten jedoch die Daten aller Shard-Ketten direkt synchronisieren dürfen, erhöht dies die Belastung der Knoten erheblich, wodurch Ethereum immer stärker zentralisiert wird. [2]
**Problem beim Wachstum des Datenvolumens:** Obwohl sich die Verarbeitungsgeschwindigkeit von Ethereum stark verbessert hat, hat die gleichzeitige Verarbeitung von Daten durch mehrere Shard-Ketten auch zu einem starken Anstieg der gespeicherten Datenmenge geführt Um ein Vielfaches schneller als zuvor werden die Anforderungen an die Speicherleistung der Knoten weiter steigen, was zu einer stärkeren Zentralisierung führt.
**Das MEV-Problem kann nicht gelöst werden:** Der Maximum Extractable Value (MEV) ist die Menge, die aus der Blockproduktion über die Standardblockbelohnung und die maximalen Treibstoffkosten hinaus extrahiert werden kann. Nachdem eine Transaktion in Ethereum initiiert wurde, wird die Transaktion im Mempool (einem Pool, der auszuführende Transaktionen enthält) platziert und wartet darauf, von den Minern gepackt zu werden. Dann können die Miner alle Transaktionen im Mempool und die Rechte der Miner sehen sind sehr begrenzt, Miner beherrschen das Einschließen, Ausschließen und Ordnen von Transaktionen. Wenn jemand einen Gewinn erzielt, indem er Bergleute besticht, um die Reihenfolge der Transaktionen im Transaktionspool anzupassen, indem er mehr Gasgebühren zahlt, ist dies ein maximal erzielbarer Wert MEV. [6]
Zum Beispiel:
Es gibt eine MEV-Methode namens „Sandwich-Angriff“ oder „Clip-Angriff“. Diese Methode zum Extrahieren von MEV dient der Überwachung großer DEX-Transaktionen in der Kette. Beispielsweise möchte jemand Altcoins im Wert von 1 Million US-Dollar auf Uniswap kaufen , und diese Methode Eine Transaktion erhöht den Preis des Altcoins erheblich. Wenn die Transaktion in den Mempool gestellt wird, kann der Überwachungsroboter die Transaktion erkennen. Zu diesem Zeitpunkt besticht der Roboter den Miner, der den Block verpackt hat Der Kauf dieser Altcoin springt vor diese Person und führt dann einen Verkaufsvorgang nach dem Kaufvorgang dieser Person durch. Es ist wie ein Sandwich, das diese Person einschließt, die große DEX-Transaktionen durchführt Die Person, die „angegriffen“ hat, hat den Altcoin aufgrund des Gewinns aus der Transaktion mit großen Beträgen erhalten, und die Person, die die Transaktion mit großen Beträgen durchgeführt hat, hat Verluste verursacht. [6]
Die Existenz von MEV hat immer einige negative Auswirkungen auf Ethereum mit sich gebracht, wie z. B. Verluste und eine schlechtere Benutzererfahrung durch „Sandwich-Angriffe“, Netzwerküberlastung durch Konkurrenz zwischen Spitzenreitern, hohe Gasgebühren und sogar Knotenzentralisierungsprobleme Mit mehr MEV-Wert kann man durch Einnahmen weiterhin mehr Anteile am Netzwerk besetzen, denn mehr Einnahmen = mehr ETH = mehr Einsatzanteile, plus die hohen Kosten, die MEV mit sich bringt (Netzwerküberlastung und hohes GAS durch Front-Running), führen zu einer kontinuierlichen Entwicklung Selbst wenn der MEV-Wert die Blockbelohnung deutlich übersteigt, führt dies zu einer Konsensinstabilität und Sicherheit des gesamten Ethereum, die durch die Sharding 1.0-Lösung nicht gelöst werden kann.
Als der Ethereum-Forscher und -Entwickler Dankrad Feist Ende 2021 Danksharding, eine neue Sharding-Lösung für Ethereum, vorschlug, wurde Danksharding von der Ethereum-Community einstimmig als die beste Lösung für eine Sharding-Erweiterung angesehen und könnte sogar eine neue Ära für Ethereum einläuten. Revolution.
Danksharding nutzt eine Reihe neuer Sharding-Ideen, um das Erweiterungsproblem von Ethereum zu lösen, d Gewährleistung der Sicherheit und Behebung der durch MEV verursachten negativen Auswirkungen.
Aus der Abbildung unten können wir ersehen, dass die Ziele von „The Surge“ und „The Scourge“ in der nächsten Ethereum-Upgrade-Phase darin bestehen, mehr als 100.000 TPS im Rollup zu erreichen und das durch MEV und andere Protokolle verursachte Zentralisierungsrisiko zu vermeiden.
Bild/Quelle: vitalik.eth Übersetzung: ethereum.cn
Wie löst Danksharding also das Expansionsproblem von Ethereum? Beginnen wir mit Dankshardings Pre-Pro-Lösung EIP-4844: Proto-Danksharding.
Prototyp EIP-4844: Proto-Danksharding – Neuer Transaktionstyp Blob
EIP-4844 führt einen neuen Transaktionstyp für Ethereum ein – Blob Transcation. Dieser neue Transaktionstyp Blob kann eine zusätzliche Plug-in-Datenbank für Ethereum bereitstellen:
Ein Blob ist etwa 128 KB groß
Eine Transaktion kann bis zu zwei Blobs übertragen – 256 KB
Jeder Block verfügt über 8 Ziel-Blobs (1 MB) und kann maximal 16 Blobs (2 MB) enthalten (das Ziel-Konzept wird im Hintergrund der Erweiterung erwähnt).
Blob-Daten werden vorübergehend gespeichert und nach einer gewissen Zeit gelöscht (aktuelle Community-Empfehlung lautet 30 Tage).
Derzeit beträgt die durchschnittliche Größe jedes Blocks in Ethereum nur etwa 85 KB. Der zusätzliche Speicherplatz, den Blob für Ethereum bringt, ist riesig. Sie müssen wissen, dass die Gesamtdatengröße aller Ethereum-Ledger seit der Geburt von Ethereum nur etwa 1 TB beträgt Blobs können jedes Jahr 2,5 TB bis 5 TB zusätzliche Daten nach Ethereum bringen, was einem Vielfachen der Datenmenge im gesamten Ethereum-Ledger entspricht.
Man kann sagen, dass die durch EIP-4844 eingeführte Blob-Transaktion maßgeschneidert für Rollup-Daten ist, die in Form von Blob auf Ethereum hochgeladen werden. Der zusätzliche Datenraum ermöglicht es Rollup, höhere TPS und niedrigere Kosten zu erzielen Dadurch wird der ursprünglich von Rollup belegte Blockraum für mehr Benutzer freigegeben.
Da Blob-Daten vorübergehend gespeichert werden, stellt der plötzliche Anstieg des Datenvolumens keine zunehmende Belastung für die Speicherleistung des Knotens dar. Wenn nur die Blob-Daten eines Monats vorübergehend gespeichert werden, beträgt das synchronisierte Datenvolumen 1 MB~ 2 MB mehr Daten, was den Bandbreitenbedarf des Knotens offenbar nicht belastet. Aus Sicht der Datenspeicherkapazität müssen Knoten nur eine feste Datenmenge von etwa 200 bis 400 GB (die Datenmenge eines Monats) herunterladen und speichern, was nur eine Erhöhung der Kosten erfordert und gleichzeitig Dezentralisierung und Sicherheit gewährleistet Die geringe Knotenlast, die Erhöhung der TPS und die Reduzierung der Kosten werden um das Zehnfache oder sogar Hundertfache berechnet. Dies ist einfach eine hervorragende Lösung, um das Skalierbarkeitsproblem von Ethereum zu lösen.
Was passiert, wenn die Daten gelöscht werden und der Benutzer auf frühere Daten zugreifen möchte?
Erstens besteht der Zweck des Ethereum-Konsensprotokolls nicht darin, die dauerhafte Speicherung aller historischen Daten sicherzustellen. Vielmehr geht es darum, ein hochsicheres Echtzeit-Bulletin-Board mit langfristigem Speicherplatz für andere dezentrale Protokolle bereitzustellen. Durch die Existenz des Bulletin Boards soll sichergestellt werden, dass die auf dem Bulletin Board veröffentlichten Daten lange genug verbleiben. Jeder Benutzer oder jedes Protokoll, das diese Daten haben möchte, hat genügend Zeit, um die Daten zu erfassen und zu speichern. Daher liegt es in der Verantwortung der Blob-Daten, diese zu speichern an andere Rollen wie Layer-2-Projektparteien, dezentrale Speicherprotokolle usw. übergeben. [3]
Danksharding – Komplette Erweiterungslösung
EIP-4844 hat den ersten Schritt in der Expansion von Ethereum rund um Rollup erreicht, aber für Ethereum reicht der durch EIP-4844 erzielte Expansionseffekt bei weitem nicht aus. Die vollständige Danksharding-Lösung erweitert die Datenmenge, die Blob übertragen kann, von 1 bis 2 MB pro Block auf 16 bis 32 MB und schlägt einen neuen Mechanismus zur Block Producer-Packager-Trennung (PBS) vor, um die durch MEV verursachten Probleme zu lösen.
Dann müssen wir wissen, welche Schwierigkeiten es geben wird, die Kapazitäten auf Basis von EIP-4844 weiter auszubauen:
**Knotenbelastung ist zu groß:** Wir wissen, dass der Blob in EIP-4844 nur 1 bis 2 MB groß ist, was völlig akzeptabel ist, um die Belastung des Knotens zu erhöhen, aber wenn das Datenvolumen des Blobs um 16 erweitert wird Mal auf 16 bis 32 MB, egal ob es sich um Datensynchronisation oder Datenspeicherung handelt, die Belastung der Knoten wird zu groß und der Grad der Dezentralisierung von Ethereum wird verringert.
**Probleme mit der Datenverfügbarkeit:** Wenn der Knoten nicht alle Blob-Daten herunterlädt, treten Datenverfügbarkeitsprobleme auf, da die Daten nicht in der Kette offen und jederzeit zugänglich sind. Der Ethereum-Knoten hat beispielsweise Zweifel an a Bestimmte Transaktion auf der Optimism Rollup Challenge, aber Optimism Rollup übergibt diese Daten nicht. Wenn Sie die Originaldaten nicht erhalten können, können Sie nicht nachweisen, dass diese Transaktion problematisch ist. Um das Problem der Datenverfügbarkeit zu lösen, müssen Sie daher sicherstellen, dass die Die Daten sind jederzeit offen und zugänglich.
Wie löst Danksharding diese Probleme?
Datenverfügbarkeitsstichprobe
Danksharding schlug eine Lösung vor – Data Availability Sampling –, um die Knotenlast zu reduzieren und gleichzeitig die Datenverfügbarkeit sicherzustellen.
Die Idee des Data Availability Sampling (DAS) besteht darin, die Daten im Blob in Datenfragmente zu zerlegen und die Knoten vom Herunterladen der Blob-Daten zur zufälligen Überprüfung der Blob-Datenfragmente wechseln zu lassen, sodass die Blob-Datenfragmente verstreut sind Jeder Knoten von Ethereum, aber die vollständigen Blob-Daten werden im gesamten Ethereum-Ledger gespeichert, vorausgesetzt, die Knoten müssen groß genug und dezentralisiert sein.
Beispiel: Die Blob-Daten werden in 10 Fragmente aufgeteilt und es gibt 100 Knoten im gesamten Netzwerk. Jeder Knoten prüft und lädt ein Datenfragment herunter und übermittelt die zufällig überprüfte Fragmentnummer an den Block Block ist: Wenn alle nummerierten Fragmente gesammelt werden können, geht Ethereum standardmäßig davon aus, dass die Daten dieses Blobs verfügbar sind, und die ursprünglichen Daten können durch Zusammenfügen der Fragmente wiederhergestellt werden. Es besteht jedoch auch eine sehr geringe Wahrscheinlichkeit, dass 100 Knoten kein Fragment mit einer bestimmten Anzahl zeichnen. In diesem Fall fehlen Daten, was die Sicherheit in gewissem Maße verringert, aber hinsichtlich der Wahrscheinlichkeit akzeptabel ist.
Danksharding verwendet zwei Technologien zur Implementierung von Data Availability Sampling (DAS): Erasure Coding und KZG Polynomial Commitment (KZG Commitment).
Löschcodierung
Erasure Coding ist eine fehlertolerante Codierungstechnologie, die es allen Ethereum-Knoten ermöglichen kann, die Originaldaten wiederherzustellen, wenn sie nur über 50 % der Datenfragmente verfügen, wodurch die Datenmenge erheblich reduziert wird Das Prinzip der Wahrscheinlichkeit des Fehlens ist komplizierter. Hier ist eine mathematische Formel, um das Prinzip grob zu erklären: [2]
Konstruieren Sie zunächst eine Funktion f(x) = ax + b und nehmen Sie beliebige 4 x-Werte
Angenommen, m = f(0) = b, n = f(1) = a + b, dann erhalten wir a = n – b, b = m
Angenommen, p = f(2), q = f(3), dann erhalten wir p = 2a + b = 2n – m, q = 3a + b = 3n – 2m
Dann werden die vier Fragmente m, n, p, q auf die Knoten im gesamten Netzwerk verteilt
Nach der mathematischen Formel müssen wir nur zwei der Fragmente finden, um herauszufinden, was die anderen beiden Fragmente sind
Wenn Sie n und m finden, können Sie q=3n-2m und p=2n-m direkt berechnen
Wenn Sie q und p finden, können Sie (2p=4n-2m)-(q=3n-2m) einsetzen, um 2p-q=n zu erhalten, und dann können Sie m direkt berechnen
Vereinfacht ausgedrückt verwendet die Löschcodierung mathematische Prinzipien, um Blob-Daten in viele Datenfragmente zu zerlegen. Ethereum-Knoten müssen nicht alle Datenfragmente sammeln. Sie müssen nur mehr als 50 % der Fragmente sammeln, um die ursprünglichen Daten des Blobs wiederherzustellen Auf diese Weise wird die Wahrscheinlichkeit einer unzureichenden Fragmentsammlung erheblich verringert, und ihre Wahrscheinlichkeit kann ignoriert werden.
KZG-Polynom-Commitment (KZG-Commitment)
KZG Polynomial Commitment (KZG Commitment) ist eine kryptografische Technologie zur Lösung des Datenintegritätsproblems der Erasure Coding. Da der Knoten die durch den Löschcode ausgeschnittenen Datenfragmente nur zufällig überprüft, weiß der Knoten nicht, ob die Datenfragmente wirklich aus den Originaldaten des Blobs stammen. Daher muss die für die Codierung verantwortliche Rolle eine KZG-Polynomverpflichtung generieren, um dies zu beweisen Die Datenfragmente des Codes sind zwar Teil der Originaldaten. Die Funktion von KZG ähnelt in gewisser Weise dem Merkle-Baum, aber die Form ist unterschiedlich. Alle Beweise von KZG basieren auf demselben Polynom.
Danksharding implementiert Data Availability Sampling (DAS) durch Erasure Coding und KZG-Polynom-Commitment, was die Belastung der Knoten erheblich reduziert, wenn die Menge der von Blobs übertragenen zusätzlichen Daten auf 16 MB bis 32 MB erweitert wird. Derzeit hat die Ethereum-Community auch eine Methode namens „ Das 2D-KZG-Schema schneidet Datenfragmente weiter ab, um Bandbreite und Rechenanforderungen zu reduzieren, aber der endgültige verwendete Algorithmus wird in der Community immer noch heftig diskutiert, einschließlich des Designs von DAS, das ebenfalls ständig optimiert und verbessert wird.
Für Ethereum löst Data Availability Sampling (DAS) das Problem der Erweiterung der Blob-Datengröße von 16 MB auf 32 MB und verringert gleichzeitig die Belastung der Knoten. Es scheint jedoch ein Problem zu geben: Wer wird die Originaldaten kodieren?
Wenn Sie Blob-Originaldaten codieren möchten, muss der Codierungsknoten über vollständige Originaldaten verfügen. Um dies zu erreichen, werden höhere Anforderungen an den Knoten gestellt. Nun, Spinach hat bereits erwähnt, dass Danksharding einen neuen Mechanismus **Block Producer-Packager Separation (PBS)** vorgeschlagen hat, um die durch MEV verursachten Probleme zu lösen. Tatsächlich löst diese Lösung nicht nur das MEV-Problem, sondern auch das Problem der Codierung Probleme.
Trennung zwischen Antragsteller und Bauträger
Erstens wissen wir, dass Data Availability Sampling (DAS) die Belastung der Knoten bei der Überprüfung von Blobs verringert und eine dezentrale Überprüfung mit geringer Konfiguration ermöglicht. Um diesen Block zu erstellen, müssen Sie jedoch über vollständige Blob-Daten verfügen und diese codieren, was zu einer Verbesserung führt Es gibt viele Anforderungen für die Proposer-Bundler-Trennung (PBS), die die Aufteilung von Knoten in zwei Rollen vorsieht: Knoten mit hoher Leistung können zu Erstellern werden, und Knoten mit geringer Leistung können zu Antragstellern werden.
Derzeit gibt es in Ethereum zwei Arten von Knoten: Vollknoten und Light-Knoten. Vollständige Knoten müssen alle Daten auf Ethereum synchronisieren, z. B. Transaktionslisten und Blockkörper. Vollständige Knoten übernehmen die beiden Rollen Blockverpackung und Blocküberprüfung. Da der vollständige Knoten alle Informationen im Block sehen kann, kann der vollständige Knoten die Transaktionen im Block neu anordnen, hinzufügen oder löschen, um den MEV-Wert zu erhalten. Leichte Knoten müssen nicht alle Daten synchronisieren, sie müssen nur den Blockheader synchronisieren, um den Block zu überprüfen. [1]
Nach der Implementierung der Proposer-Packager-Trennung (PBS):
Knoten mit einer Hochleistungskonfiguration können zu Buildern werden. Die Builder müssen lediglich dafür verantwortlich sein, Blob-Daten herunterzuladen, zu kodieren und Blöcke zu erstellen und diese dann zur Stichprobenprüfung an andere Knoten zu senden hoch, es wird relativ zentralisiert sein.
Knoten mit geringerer Leistungskonfiguration können nur die Gültigkeit der Daten überprüfen und Blockheader erstellen und senden. Für Antragsteller sind jedoch geringere Anforderungen an das Synchronisierungsdatenvolumen und die Bandbreite erforderlich.
PBS realisiert die Arbeitsteilung zwischen den Knoten, indem die Rollen der Verpackung und Verifizierung getrennt werden. Knoten mit hoher Leistungskonfiguration sind für das Herunterladen aller Daten zur Kodierung und Verteilung verantwortlich, und Knoten mit geringer Leistungskonfiguration sind für Stichproben und Verifizierung verantwortlich das MEV-Problem gelöst?
Zensurwiderstandsliste (crList)
Da PBS die Arbeit des Packens und der Verifizierung trennt, hat der Packager (Builder) tatsächlich eine größere Möglichkeit, Transaktionen zu überprüfen und die Transaktionen, die er einfügen möchte, nach Belieben zu sortieren und einzufügen, aber die Zensur -resistente Liste (crList) löst diese Probleme.
Mechanismus der zensurresistenten Liste (crList): [1]
Bevor der Builder die Blocktransaktion verpackt, veröffentlicht der Antragsteller zunächst eine zensurresistente Liste (crList). Diese crList enthält alle Transaktionen im Mempool.
Der Packager (Builder) kann nur die Transaktionen in crList packen und sortieren, was bedeutet, dass der Packager weder seine eigene private Transaktion einfügen kann, um MEV zu erhalten, noch eine Transaktion absichtlich ablehnen kann (es sei denn, das Gaslimit ist voll).
Nach dem Packen sendet der Builder die endgültige Version des Transaktionslisten-Hashs an den Antragsteller. Der Antragsteller wählt eine der Transaktionslisten aus, um einen Blockheader zu generieren, und sendet ihn.
Wenn der Knoten Daten synchronisiert, erhält er den Blockheader vom Antragsteller (Proposer) und anschließend den Blockkörper vom Packager (Builder), um sicherzustellen, dass der Blockkörper die endgültig ausgewählte Version ist.
Die negativen Auswirkungen von MEV wie „Sandwich-Angriff“ werden durch die Anti-Zensur-Liste (crList) behoben. Knoten können keine ähnlichen MEV mehr durch Einfügen privater Transaktionen erhalten.
Der konkrete Implementierungsplan von Ethereum für PBS wird noch diskutiert. Der aktuelle mögliche vorläufige Implementierungsplan ist Dual-Slot-PBS.
Neuer PBS (Zwei-Slot-Proposer-Builder-Trennung)
Dual-Slot-PBS verwendet ein Gebotsmodell, um Blöcke zu bestimmen:[2]
Nach Erhalt der crList erstellt der Builder den Blockheader der Transaktionsliste und der Gebote
Der Antragsteller wählt den Block-Header und -Builder aus, der im endgültigen Gebot erfolgreich ist, und der Antragsteller erhält die Gebühr für das Gewinnergebot bedingungslos (unabhängig davon, ob ein gültiger Block generiert wird oder nicht).
Das Verifizierungskomitee (Komitees) bestätigt den siegreichen Blockkopf
Der Bauunternehmer gibt den siegreichen Blockkörper bekannt
Das Verifizierungskomitee (die Ausschüsse) bestätigt den siegreichen Blockkörper und führt eine Verifizierungsabstimmung durch (bei Erfolg wird der Block erstellt. Wenn der Paketierer den Blockkörper absichtlich nicht angibt, wird davon ausgegangen, dass der Block nicht existiert).
Obwohl der Builder immer noch MEV erhalten kann, indem er die Transaktionssequenz anpasst, führt der Gebotsmechanismus von Dual-Slot-PBS zu einer „Involution“ bei diesen Paketierern. Wenn jeder ein Angebot abgeben muss, um um Blöcke zu konkurrieren, werden die von den zentralisierten Paketierern durch MEV erzielten Gewinne kontinuierlich gekürzt und die endgültigen Gewinne werden an die dezentralen Anbieter (Antragsteller) verteilt. Dies löst das Problem. Es löst das Problem der zentralisierten Paketierer wird durch die Übernahme von MEV immer stärker zentralisiert.
Allerdings weist Dual-Slot-PBS einen Designfehler auf: Wir sehen, dass der Name dieses Designs „Two-Slot“ lautet, was bedeutet, dass es zwei Slots gibt, was bedeutet, dass in diesem Schema die effektive Blockgenerierungszeit beträgt auf 24 Sekunden verlängert (ein Slot = 12 Sekunden), und die Ethereum-Community hat aktiv darüber diskutiert, wie dieses Problem gelöst werden kann.
Zusammenfassen
Danksharding bietet eine transformative Lösung für Ethereum, um das „unmögliche Blockchain-Dreieck“ zu lösen, das darin besteht, Skalierbarkeit zu erreichen und gleichzeitig die Dezentralisierung und Sicherheit von Ethereum zu gewährleisten:
Durch die Front-End-Lösung EIP-4844: Proto-Danksharding wird ein neuer Transaktionstyp Blob eingeführt. Das vom Blob übertragene zusätzliche Datenvolumen von 1 MB bis 2 MB kann Ethereum dabei helfen, höhere TPS und niedrigere Rollup-Kosten zu erzielen.
Data Availability Sampling (DAS) wird durch Erasure Coding und KZG-Polynom-Commitment implementiert, sodass Knoten nur einige Datenfragmente nach dem Zufallsprinzip überprüfen müssen, um die Verfügbarkeit von Daten zu überprüfen und die Belastung der Knoten zu verringern.
Durch die Implementierung von Data Availability Sampling (DAS) wird das zusätzliche Datenvolumen von Blob auf 16 MB bis 32 MB erweitert, wodurch der Erweiterungseffekt auf ein höheres Niveau gehoben wird.
Durch die Proposer-Packager-Trennung (PBS) wird die Arbeit des Verifizierens und Verpackens von Blöcken in zwei Knotenrollen aufgeteilt, wodurch die Dezentralisierung von Verpackungsknoten und die Dezentralisierung von Verifizierungsknoten realisiert werden.
Die durch MEV verursachten negativen Auswirkungen werden durch die Anti-Zensur-Liste (crList) und das Dual-Slot-PBS erheblich reduziert. Der Packager kann keine privaten Transaktionen einfügen oder eine bestimmte Transaktion zensieren.
Wenn nichts anderes passiert, wird die Front-End-Lösung EIP-4844 von Danksharding nach dem Upgrade von Ethereum Shanghai offiziell im Cancun-Upgrade implementiert. Der direkteste Vorteil nach der Implementierung der EIP-4844-Lösung ist das Rollup und Rollup in der Layer-2-Ökologie . Höhere TPS und niedrigere Kosten eignen sich sehr gut für Hochfrequenzanwendungen in der Kette. Wir können uns genauso gut vorstellen, dass einige „Killeranwendungen“ entstehen. Die durch Danksharding erreichte zentralisierte Blockproduktion + dezentrale Überprüfung + Zensurresistenz wird Ethereum eine neue Runde öffentlicher Kettenerzählungen bescheren. Zusätzlich zu Schicht 2 werden die modulare Blockchain und Ethereum nach Danksharding kollidieren, um welche Art von chemischer Reaktion zu erzeugen?
Spinach glaubt, dass die Implementierung von Danksharding die gesamten Spielregeln neu schreiben wird und Ethereum die Blockchain-Industrie in eine neue Ära führen wird!
Verweise
[1] Datenverfügbarkeit, Speichererweiterung der Blockchain
[2] Verständnis des neuen Upgrade-Plans von Ethereum in einem Artikel Danksharding
[3] Proto-Danksharding FAQ – HackMD
[4] Was genau ist „Danksharding“ in der Populärwissenschaft von V?
[5] Empfohlen von V God丨Um ein tiefgreifendes Verständnis der Sharding-Roadmap von Ethereum zu erlangen, reicht dieser Bericht aus
[6] Buidler DAO-Artikel: Wie kann man NFTs vor Hackern retten, nachdem ihre Brieftasche gestohlen wurde?
[7] Wiederholt sich die Geschichte? Eine detaillierte Erklärung von Ethereum 2.0 und Hard Forks