Geschrieben von: Hakeen
1. Ethereums Upgrade-Roadmap M2SVPS
Die Fusion
In der Merge-Phase wird der POW-Konsensmechanismus auf POS umgestellt und die Beacon-Ketten werden zusammengeführt. Zum besseren Verständnis vereinfachen wir die Ethereum-Struktur in der folgenden Abbildung:
Lassen Sie uns zunächst definieren, was Sharding hier ist: Ein einfaches Verständnis ist der Prozess der horizontalen Aufteilung der Datenbank, um die Last zu verteilen.
Nach dem Wechsel zu POS: Blockantragsteller und Blockvalidierer werden getrennt, und der POS-Workflow ist wie folgt (verstanden anhand der obigen Abbildung):
Transaktionen werden auf Rollup festgeschrieben. Validatoren fügen Transaktionen zu Shard-Blöcken hinzu. Die Beacon-Kette wählt Validatoren aus, um neue Blöcke vorzuschlagen. Die verbleibenden Validatoren bilden zufällige Ausschüsse und validieren Vorschläge auf Shards
Sowohl das Vorschlagen eines Blocks als auch der Nachweis des Vorschlags müssen innerhalb eines Slots, normalerweise 12 Sekunden, abgeschlossen sein. Alle 32 Slots bilden einen Epochenzyklus, und jede Epoche unterbricht die Validatorsortierung und wählt das Komitee neu.
Nach der Fusion wird Ethereum die Proposer-Builder-Trennung (PBS) für die Konsensschicht implementieren. Vitalik glaubt, dass das Endziel aller Blockchains eine zentralisierte Blockproduktion und eine dezentrale Blockverifizierung sein wird. Da die geshardteten Ethereum-Blockdaten sehr dicht sind, ist aufgrund der hohen Anforderungen an die Datenverfügbarkeit eine Zentralisierung der Blockproduktion notwendig. Gleichzeitig muss es eine Möglichkeit geben, einen dezentralen Satz von Validatoren zu verwalten, die Blöcke validieren und Stichproben zur Datenverfügbarkeit durchführen können.
Miner und Blockverifizierung sind getrennt. Miner erstellen Blöcke und übermitteln die Blöcke dann an Validatoren. Validatoren bieten an, ihre eigenen Blöcke auszuwählen, und dann stimmen die Validatoren ab, um zu entscheiden, ob der Block gültig ist.
Sharding ist eine Partitionierungsmethode, mit der Rechenaufgaben und Speicherarbeitslasten in einem P2P-Netzwerk verteilt werden können. Nach dieser Verarbeitungsmethode muss nicht jeder Knoten für die Verarbeitung der Transaktionslast des gesamten Netzwerks verantwortlich sein, sondern muss nur die damit verbundenen Informationen verwalten seine Partitions- (oder Sharding-)Informationen reichen aus. Jeder Shard verfügt über ein eigenes Netzwerk von Validatoren oder Knoten.
Sicherheitsprobleme beim Sharding: Wenn das gesamte Netzwerk beispielsweise über 10 Shard-Ketten verfügt, erfordert die Zerstörung des gesamten Netzwerks 51 % der Rechenleistung, während die Zerstörung eines einzelnen Shards nur 5,1 % der Rechenleistung erfordert. Zu den nachfolgenden Verbesserungen gehört daher ein SSF-Algorithmus, der Angriffe mit einer Rechenleistung von 51 % effektiv verhindern kann. Laut Vitaliks Zusammenfassung ist die Umstellung auf SSF eine mehrjährige Roadmap. Auch wenn derzeit viel Arbeit geleistet wird, wird es eine der wichtigsten Änderungen sein, die später in Ethereum umgesetzt werden, und weit hinter dem PoS-Proof-Mechanismus, Sharding und Ethereum zurückbleiben Verkle-Baum. Nach vollständigem Rollout.
Die Beacon-Kette ist für die Generierung von Zufallszahlen, die Zuweisung von Knoten zu Shards, die Erfassung von Snapshots einzelner Shards und andere verschiedene Funktionen verantwortlich. Sie ist für die Vervollständigung der Kommunikation zwischen Shards und die Koordinierung der Synchronisierung des Netzwerks verantwortlich.
Die Ausführungsschritte der Beacon-Kette sind wie folgt:
Der Blockproduzent übermittelt den Blockheader zusammen mit dem Gebot. Der Blocker (Verifizierer) in der Beacon-Kette wählt den erfolgreichen Blockkopf und das Gebot aus und erhält die Gebühr für das Gewinnergebot bedingungslos, unabhängig davon, ob der Blockpaketierer schließlich den Blockkörper generiert. Das Komitee (zufällig unter den Validatoren ausgewählt) stimmt für die Bestätigung des erhaltenen Blockheaders. Der Blockpacker legt den Blockkörper offen.
Der Anstieg
Das Hauptziel dieser Route besteht darin, die Rollup-zentrierte Skalierung voranzutreiben. Surge bezieht sich auf die Hinzufügung von Ethereum-Sharding, einer Skalierungslösung, die nach Angaben der Ethereum Foundation eine Second-Layer-Blockchain mit niedrigen Gasgebühren weiter ermöglichen, die Kosten für Rollup- oder gebündelte Transaktionen senken und es Benutzern einfacher machen wird, sichere Knoten zu betreiben das Ethereum-Netzwerk.
Das Diagramm kann weiterhin anhand des folgenden vereinfachten Diagramms verstanden werden:
Nehmen Sie als Beispiel das Funktionsprinzip von zkrollup: Zkrollup ist in einen Sequenzer und einen Aggregator unterteilt. Der Sequenzer ist dafür verantwortlich, Benutzertransaktionen zu sortieren, sie in Stapel zu packen und an den Aggregator zu senden. Der Aggregator führt die Transaktion aus, beginnend mit der vorherigen Statuswurzel (vorherige Statuswurzel), generiert die Poststatuswurzel (Poststatuswurzel) und generiert dann den Beweis (Beweis). Der Aggregator sendet schließlich die vorherige Statuswurzel und die Poststatuswurzel , Transaktionsdaten und Nachweis an L1 Der Vertrag ist dafür verantwortlich, zu überprüfen, ob das Zertifikat gültig ist, und die Transaktionsdaten werden in Anrufdaten gespeichert. Die Datenverfügbarkeit von Zkrollup ermöglicht es jedem, den globalen Status des Kontos basierend auf den in der Kette gespeicherten Transaktionsdaten wiederherzustellen.
Die Kosten für die Verwendung von Anrufdaten sind jedoch sehr hoch, sodass das gesamte EIP-4844-Protokoll (das sich jederzeit ändern kann) vorschlägt, die Größe des Transaktionsblocks auf 1 bis 2 MB zu ändern und so eine solide Grundlage für zukünftiges Rollup und Daten-Sharding zu schaffen . Die aktuelle Blockgröße von Ethereum beträgt etwa 60 KB bis 100 KB. Am Beispiel von EIP-4844 kann die Blockgrößenbeschränkung um das 10- bis 34-fache erhöht werden. Dieses Blockformat wird Blob (auch Daten-Shard genannt) genannt.
Die Geißel
In dieser Phase ist Scourge eine Ergänzung zur Roadmap und wird hauptsächlich zur Lösung von MEV-Problemen verwendet. Was ist MEV?
Der vollständige Name von MEV lautet Miner Extractable Value / Maximal Extractable Value. Dieses Konzept wurde erstmals im Zusammenhang mit dem Arbeitsnachweis angewendet und hieß ursprünglich „Miner Extractable Value“. Dies liegt daran, dass Miner beim Proof-of-Work Rollenfunktionen wie das Einschließen, Ausschließen und Ordnen von Transaktionen beherrschen. Nach dem Übergang zum Proof-of-Stake per Zusammenführung werden jedoch die Validatoren für diese Rollen verantwortlich sein und das Mining wird nicht mehr angewendet (die hier vorgestellte Methode zur Wertextraktion bleibt nach diesem Übergang erhalten, daher ist eine Namensänderung erforderlich). Um weiterhin das gleiche Akronym zu verwenden, um Kontinuität zu gewährleisten und gleichzeitig die gleiche Grundbedeutung beizubehalten, wird jetzt „Maximal Extractable Value“ als umfassendere Alternative verwendet.
Der Arbitrageraum umfasst:
Durch die Komprimierung des Speicherplatzes wird die Preisdifferenz der Gasgebühren ermittelt; Referee-Front-Running: Umfangreiche Suche nach Transaktionen im Mempool, die Maschine führt lokal Berechnungen durch, um zu sehen, ob es profitabel ist, und initiiert in diesem Fall die gleiche Transaktion mit ihr eigene Adresse. Und höhere Gasgebühren verwenden; Liquidationsziele finden: Roboter konkurrieren darum, die Blockchain-Daten so schnell wie möglich zu analysieren, um festzustellen, welche Kreditnehmer liquidiert werden können, und werden dann die ersten, die Liquidationstransaktionen einreichen und selbst Liquidationsgebühren einziehen. Sandwich-Transaktionen: Suchende überwachen große Transaktionen auf DEX innerhalb des Mempools. Beispielsweise möchte jemand 10.000 UNI mit DAI auf Uniswap kaufen. Solche großen Transaktionen hätten erhebliche Auswirkungen auf das UNI/DAI-Paar und könnten den Preis von UNI im Vergleich zu DAI erheblich erhöhen. Der Suchende kann die ungefähren Preisauswirkungen dieser großen Transaktion auf das UNI/DAI-Paar berechnen und den optimalen Kaufauftrag unmittelbar vor der großen Transaktion ausführen, um UNI zu einem niedrigen Preis zu kaufen, und dann den Verkaufsauftrag unmittelbar nach der großen Transaktion ausführen. wobei der Großauftrag zu einem höheren Verkaufspreis führte.
Nachteile von MEV:
Einige Formen von MEV, wie z. B. Sandwich-Transaktionen, können zu einer deutlich schlechteren Benutzererfahrung führen. Benutzer, die in der Mitte gefangen sind, müssen mit einem höheren Slippage und einer schlechteren Handelsausführung rechnen. Auf der Netzwerkebene führen die allgemeinen Spitzenreiter und die Mining-Gebühren-Auktionen, an denen sie häufig teilnehmen (wenn zwei oder mehr Pioniere die Mining-Gebühren ihrer eigenen Transaktionen schrittweise erhöhen, sodass ihre Transaktionen in den nächsten Block gebündelt werden), zum Netzwerk Überlastung und hohe Mining-Gebühren durch andere, die versuchen, normale Transaktionen durchzuführen. Zusätzlich zu dem, was innerhalb eines Blocks geschieht, kann MEV auch blockübergreifend schädliche Auswirkungen haben. Wenn der in einem Block verfügbare MEV die Standardblockbelohnung deutlich übersteigt, könnten Miner einen Anreiz haben, den Block zu reminen und MEV für sich selbst zu erobern, was zu einer Neuorganisation der Blockchain und einer Instabilität des Konsenses führt.
Der größte Teil des MEV wird von unabhängigen Netzwerkteilnehmern extrahiert, die als „Sucher“ bezeichnet werden. Suchende führen komplexe Algorithmen auf Blockchain-Daten aus, um profitable MEV-Möglichkeiten zu erkennen, und es gibt Bots, die diese profitablen Transaktionen automatisch an das Netzwerk übermitteln. Das MEV-Problem bei Ethereum besteht darin, dass Bots zur Ausnutzung von Netzwerktransaktionen eingesetzt werden, was zu Überlastungen und hohen Gebühren führt.
Der Rand
Verge wird „Verkle Tree“ (einen mathematischen Beweis) und „Stateless Client“ implementieren. Diese technischen Upgrades ermöglichen es Benutzern, Netzwerkvalidatoren zu werden, ohne große Datenmengen auf ihren Computern speichern zu müssen. Dies ist auch einer der Schritte rund um die Rollup-Erweiterung. Wie bereits erwähnt, besteht das einfache Arbeitsprinzip des ZK-Rollups darin, dass der Aggregator den Beweis übermittelt und der Verifizierungsvertrag auf Ebene 1 nur die KZG-Verpflichtung im Blob und die generierten Daten überprüfen muss nachweisen. Hier finden Sie eine kurze Einführung in die Verpflichtung von KZG, sicherzustellen, dass alle Transaktionen einbezogen werden. Da beim Rollup Teiltransaktionen übermittelt und Nachweise generiert werden können, wird bei Verwendung von KZG sichergestellt, dass alle Transaktionen in die Erstellung von Nachweisen einbezogen werden.
The Verge stellt sicher, dass die Überprüfung sehr einfach ist. Sie müssen nur N Bytes an Daten herunterladen und grundlegende Berechnungen durchführen, um den vom Rollup übermittelten Beweis zu überprüfen.
Es ist erwähnenswert, dass ZK Rollup viele Lösungen bietet, wie zum Beispiel Stark, Snark oder Bulletproof. Jedes Schema verfolgt einen anderen Nachweis- und Verifizierungsansatz, daher gibt es Kompromisse. SNARKs sind derzeit einfacher zu verwenden als die STARKs-Technologie und die Technologie ist auch umfassender. Daher verwenden viele Projekte zu Beginn SNARKs, aber mit der Iteration der STARKs-Technologie werden sie schließlich auf STARKs zurückgreifen, die gegen Quantenangriffe resistent sind. Obwohl eine der wichtigsten Verbesserungen von Ethereum in EIP-4844 zur Anpassung an das Rollup das Transaktionsformat Blob ist, das die Blockkapazität erweitert, liegt der Hauptengpass aller aktuellen Zero-Knowledge-Proofs immer noch im eigenen Proof-Algorithmus Einerseits kann es durch die Verbesserung des Algorithmus gelöst werden, andererseits wird das Beweisproblem durch Stapeln von Hardware verbessert, was auch zur Entstehung des ZK-Mining-Tracks führte. Wer Interesse hat, kann sich diesen Artikel ansehen.
Die Säuberung
Durch die Säuberung wird der Speicherplatz reduziert, der zum Speichern von ETH auf einer Festplatte erforderlich ist, um das Ethereum-Protokoll zu vereinfachen und die Notwendigkeit zu beseitigen, dass Knoten den Verlauf speichern müssen. Dadurch kann die Bandbreite des Netzwerks erheblich verbessert werden.
EIP-4444:
Clients müssen aufhören, historische Header, Textkörper und Empfänger auf der P2P-Ebene bereitzustellen, die älter als ein Jahr sind. Clients können diese historischen Daten lokal bereinigen. Die Bewahrung der Geschichte von Ethereum ist von grundlegender Bedeutung, und ich glaube, dass es verschiedene Out-of-Band-Möglichkeiten gibt, dies zu erreichen. Historische Daten können über Torrent-Magnet-Links oder Netzwerke wie IPFS gepackt und geteilt werden. Darüber hinaus können Systeme wie Portal Network oder The Graph verwendet werden, um historische Daten zu erhalten. Der Client sollte den Import und Export historischer Daten ermöglichen. Kunden können Skripte bereitstellen, um Daten abzurufen/zu validieren und sie automatisch zu importieren.
Der Luxus
Diese Route besteht hauptsächlich aus einigen schrittweisen Optimierungskorrekturen, wie z. B. Kontoabstraktion, EVM-Optimierung und Zufallszahlenschema VDF.
Die hier erwähnte Account Abstraction (AA) war schon immer das erste Ziel, das Layer 2 der ZK-Serie erreichen möchte. Was ist also Kontoabstraktion? Nach der Implementierung der Kontoabstraktion kann ein Smart-Contract-Konto auch aktiv Transaktionen initiieren, ohne auf den „Meta-Transaktions“-Mechanismus angewiesen zu sein (dies wurde in EIP-4844 vorgeschlagen).
Bei Ethereum werden Konten in Vertragskonten und externe Konten unterteilt. Derzeit gibt es in Ethereum nur eine Art von Transaktion, die von einer externen Adresse initiiert werden muss. Vertragsadressen können keine Transaktionen aktiv initiieren. Daher muss jede Änderung des Vertragsstatus auf einer von einer externen Adresse initiierten Transaktion beruhen. Unabhängig davon, ob es sich um ein Multi-Signatur-Konto, einen Währungsmixer oder eine Änderung der Smart-Contract-Konfiguration handelt, muss sie von mindestens einem externen Konto ausgelöst werden .
Unabhängig davon, welche Anwendung auf Ethereum verwendet wird, müssen Benutzer Ethereum besitzen (und das Risiko von Ethereum-Preisschwankungen tragen). Zweitens müssen sich Benutzer mit komplexer Kostenlogik, Gaspreis, Gaslimit und Transaktionsblockierung auseinandersetzen. Diese Konzepte sind für Benutzer zu komplex. Viele Blockchain-Wallets oder -Anwendungen versuchen, die Benutzererfahrung durch Produktoptimierung zu verbessern, allerdings mit geringer Wirkung.
Ziel der Account-zentrierten Lösung ist es, auf Basis einer intelligenten Vertragsverwaltung ein Konto für den Nutzer zu erstellen. Die Vorteile der Implementierung der Kontoabstraktion sind:
Der aktuelle Vertrag kann ETH halten und eine Transaktion direkt mit allen Unterschriften einreichen. Der Benutzer muss nicht unbedingt Gasgebühren für die Transaktion zahlen, es hängt vollständig vom Projekt ab. Aufgrund der Implementierung der benutzerdefinierten Kryptografie ist die Verwendung von ESCDA-Ellipsenkurven für Signaturen in Zukunft nicht zwingend erforderlich. Als Signaturmethoden können künftig die Fingerabdruckerkennung, die Gesichtserkennung, die Biometrie und andere Technologien verwendet werden. Dies verbessert das Interaktionserlebnis des Benutzers mit Ethereum erheblich.
2. Modularisierung von Ethereum
Das gesamte Ethereum verzeichnet derzeit einen Trend zur Modularisierung, und die Ausführungsschicht ist für Schicht 2 verantwortlich (z. B. Arbitrum, Zksync, Starknet, Polygon Zkevm usw.). Sie sind dafür verantwortlich, die Transaktionen der Benutzer auf L2 auszuführen und Nachweise einzureichen. Schicht 2 verwendet im Allgemeinen die OP-Technologie/ZK-Technologie. Theoretisch ist die TPS der ZK-Technologie viel höher als die der OP. Derzeit befindet sich eine große Anzahl von Ökosystemen im OP-System, aber in Zukunft wird die ZK-Technologie verbessert , werden immer mehr Anwendungen in die ZK-Abteilung migriert. Dieser Abschnitt enthält eine detaillierte Beschreibung der Roadmap, ergänzt durch das Warum und Wie.
Derzeit trennt Ethereum nur die Ausführungsschicht. Tatsächlich sind andere Schichten noch miteinander vermischt. In Celestias Vision führt die Ausführungsschicht nur zwei Dinge aus: Für eine einzelne Transaktion führt sie die Transaktion aus und es treten Statusänderungen für Transaktionen im selben Stapel auf. Sie berechnet die Statuswurzel des Stapels. Ein Teil der aktuellen Arbeit an der Ethereum-Ausführungsschicht ist Rollup zugeordnet, das als StarkNet, zkSync, Arbitrum und Optimism bekannt ist.
Jetzt erkunden Optimismus, Polygon, Starknet, Zksync usw. den Weg der Modularität.
Optimism schlug einen Grundstein/Op-Stack vor, Polygon entwickelt auch Polygon Avail als Datenverfügbarkeitsschicht, und Supernets werden verwendet, um die Kettenerstellung zu vereinfachen und Validator-Sets gemeinsam zu nutzen.
Abrechnungsschicht: Darunter versteht man den Prozess der Überprüfung der Gültigkeit des oben erwähnten Pre-State-Root, Post-State-Root, Proof (zkRollup) oder Betrugsnachweises (Optimistic Rollup) durch den Rollup-Vertrag in der Hauptkette. Konsensschicht: Unabhängig davon, ob PoW, PoS oder andere Konsensalgorithmen verwendet werden, besteht die Konsensschicht darin, einen Konsens über etwas im verteilten System zu erzielen, dh einen Konsens über die Gültigkeit des Zustandsübergangs zu erzielen (die Wurzel vor dem Zustand ist). berechnet und in die Post-State-Wurzel umgerechnet). Im Kontext der Modularität haben die Siedlungsschicht und die Konsensschicht etwas ähnliche Bedeutungen, daher vereinheitlichen einige Forscher die Siedlungsschicht und die Konsensschicht. Datenverfügbarkeitsschicht: Stellen Sie sicher, dass Transaktionsdaten vollständig auf die Datenverfügbarkeitsschicht hochgeladen werden und der Verifizierungsknoten alle Statusänderungen über die Daten in dieser Schicht reproduzieren kann.
Zu unterscheiden ist hier der Unterschied zwischen Datenverfügbarkeit und Datenspeicherung:
Die Datenverfügbarkeit unterscheidet sich deutlich von der Datenspeicherung. Erstere konzentriert sich darauf, ob die im letzten Block veröffentlichten Daten verfügbar sind, während es bei letzterer darum geht, Daten sicher zu speichern und sicherzustellen, dass bei Bedarf auf sie zugegriffen werden kann.
1. Verschiedene Rollups auf der Abrechnungsebene
Aus Sicht der Abrechnungsschicht wird derzeit davon ausgegangen, dass der Schwerpunkt des Rollups auf der ZK-Serie liegt. Wenn das Rollup des ZK-Systems zur Verbesserung der Größe, des Gasverbrauchs und der Kosten des ZK-Proof-Systems verwendet und mit Rekursion und Parallelverarbeitung kombiniert wird, kann sein TPS erheblich erweitert werden. Beginnen wir also mit dem ZK-Rollup.
Mit der Entwicklung der Ethereum-Erweiterung betrachtet Vitalik die Zero Knowledge Proof (ZKP)-Technologie als die Lösung, die voraussichtlich das Endergebnis des Expansionskampfes sein wird.
Der Kern von ZKP besteht darin, jemandem den Nachweis zu ermöglichen, dass er etwas weiß oder besitzt. Ich kann zum Beispiel nachweisen, dass ich den Schlüssel zur Tür habe, ohne ihn herausziehen zu müssen. Diese Technologie beweist, dass Sie das Passwort eines Kontos kennen, ohne es eingeben zu müssen und das Risiko einzugehen, preisgegeben zu werden. Sie hat Auswirkungen auf die Privatsphäre, die Verschlüsselung, das Geschäft und sogar die nukleare Abrüstung. Gewinnen Sie ein tieferes Verständnis mit einer modifizierten Version von Yaos Millionärsproblem: In diesem Problem geht es um zwei Millionäre, Alice und Bob, die wissen wollen, wer von ihnen reicher ist, ohne ihr tatsächliches Vermögen preiszugeben.
Geht man davon aus, dass die monatliche Miete für eine Wohnung 1.000 US-Dollar beträgt, müssten Sie, um als Miete zu gelten, mindestens das 40-fache einer Monatsmiete zahlen. Dann müssen wir (Mieter) nachweisen, dass unser Jahreseinkommen mehr als 40.000 US-Dollar beträgt. Aber der Vermieter wollte nicht, dass wir Lücken finden, also entschied er sich, die konkrete Miete nicht zu veröffentlichen. Seine Absicht war es zu testen, ob wir die Standards erfüllten, und die Antwort war nur, ob wir die Standards erfüllten oder nicht, und er war es nicht für den konkreten Betrag verantwortlich.
Es gibt jetzt zehn Kästchen, die in 10.000-Dollar-Schritten mit 10.000 bis 100.000 US-Dollar markiert sind. Jeder hat einen Schlüssel und einen Schlitz. Der Besitzer ging mit der Kiste in das Zimmer, zerstörte neun Schlüssel und nahm den Schlüssel aus der Kiste mit der Aufschrift „40.000 $“.
Das Jahresgehalt des Mieters beträgt 75.000 US-Dollar. Der Bankagent überwacht die Ausstellung eines Dokuments zum Nachweis der Vermögenswerte. Der Kern dieses Dokuments ist die Vermögensaufstellung der Bank zur Überprüfung des Anspruchsdokuments. Anschließend legen wir die Datei in den 10.000- bis 70.000-KB-Behälter ab. Anschließend öffnet der Hausbesitzer mit dem 40.000-Schlüssel die Kiste, und wenn er das überprüfbare Anspruchsdokument darin sieht, stellt er fest, dass der Mieter die Kriterien erfüllt.
Dazu gehören die Ausstellung einer Bescheinigung über die Vermögenskonformität durch den Anmelder (Bank) und die Überprüfung der Qualifikation des Mieters durch den Prüfer (Hausbesitzer) anhand des Schlüssels. Es wird noch einmal betont, dass es für die Überprüfungsergebnisse nur zwei Optionen gibt – qualifiziert oder nicht qualifiziert – und dass hierfür nicht die konkrete Höhe des Vermögens des Mieters erforderlich ist und dies auch nicht erforderlich sein kann.
Wir können weiterhin die folgende Abbildung als Verständnis verwenden. Transaktionen werden auf Ebene 2 ausgeführt und Transaktionen werden auf Shards übermittelt. Schicht 2 übernimmt im Allgemeinen die Form eines Rollups, d. h. mehrere Transaktionen werden in einem Stapel auf Schicht 2 gepackt, um die Transaktionen zu verarbeiten, und dann an den Rollup-Smart-Vertrag von Schicht 1 übermittelt. Dieser enthält die alten und neuen Staatswurzeln. Der Vertrag auf Ebene 1 überprüft, ob die beiden Staatswurzeln übereinstimmen. Wenn sie übereinstimmen, wird die alte Staatswurzel in der Hauptkette durch die neue Staatswurzel ersetzt. Wie kann man also überprüfen, ob die nach der Stapelverarbeitung erhaltene Statuswurzel korrekt ist? Hier sind das abgeleitete optimistische Rollup und das ZK-Rollup. Betrugssichere und ZK-Technologie werden jeweils zur Transaktionsbestätigung und zur Status-Root-Verifizierung verwendet.
Schicht 2 (Rollup) entspricht hier dem Anmelder (Bank) im obigen Beispiel. Sein Verpackungsvorgang ist der Deklarationsvorgang. Er deklariert nicht den spezifischen Betrag, sondern bestätigt, ob der Standard erfüllt ist. Was verpackt und an Schicht 1 übermittelt wird, ist dieses beanspruchbare Deklarationsdokument. Der Kern der Überprüfung des alten und neuen Status besteht darin, dass der Vermieter anhand des Schlüssels überprüft, ob die Finanzkraft des von ihm erwarteten Mieters den Standards entspricht. Das Problem der staatlichen Wurzelverifizierung besteht darin, die von der Bank vorgelegte Erklärung so zu formulieren, dass das Problem glaubhaft gemacht wird.
Basierend auf einem optimistischen, also betrugssicheren Rollup, zeichnet der Rollup-Vertrag der Hauptkette eine vollständige Aufzeichnung der internen Status-Root-Änderungen des Rollups sowie den Hash-Wert jedes Batches auf (der die Status-Root-Änderung auslöst). Wenn jemand feststellt, dass die neue Statuswurzel, die einem bestimmten Batch entspricht, falsch ist, kann er in der Hauptkette einen Beweis dafür veröffentlichen, dass die von diesem Batch generierte neue Statuswurzel falsch ist. Der Vertrag überprüft den Beweis, und wenn die Überprüfung erfolgreich ist, werden alle Stapelverarbeitungstransaktionen nach der Stapelverarbeitung zurückgesetzt.
Die Überprüfungsmethode entspricht hier der Einreichung eines überprüfbaren Vermögensdeklarationsdokuments durch den Anmelder (Bank) und der anschließenden Veröffentlichung aller Vermögensdokumente in der Kette. Die Daten müssen ebenfalls in der Kette veröffentlicht werden, und andere Herausforderer berechnen auf der Grundlage des Originals Überprüfen Sie, ob die Vermögensdokumente Fehler oder Fälschungen enthalten. Bei Problemen erfolgt eine Anfechtung. Bei erfolgreicher Anfechtung erfolgt eine Klageerhebung bei der Bank. Das wichtigste Problem hierbei ist die Notwendigkeit, dem Herausforderer Zeit einzuräumen, Daten zu sammeln und die Echtheit des Dokuments zu überprüfen.
Beim Rollup mit Zero Knowledge Proof (ZKP)-Technologie enthält jeder Stapel einen kryptografischen Beweis namens ZK-SNARK. Banken verwenden kryptografische Beweistechnologie, um Vermögensdeklarationsdokumente zu erstellen. Auf diese Weise besteht keine Notwendigkeit, Zeit für Herausforderer zu reservieren, und daher gibt es keine Rolle als Herausforderer.
2. Der Grund, warum das Rollup der ZK-Serie derzeit nicht so gut ist wie erwartet
Derzeit wurde das Polygon-basierte Hermez veröffentlicht, und das ZKsync-Dev-Mainnet und das Starknet-Mainnet wurden ebenfalls gestartet. Ihre Transaktionsgeschwindigkeit scheint jedoch zu weit hinter unserer Theorie zurück zu sein. Insbesondere Benutzer von Starknet können deutlich spüren, dass die Geschwindigkeit seines Mainnets überraschend langsam ist. Der Grund dafür ist, dass es immer noch sehr schwierig ist, Beweise mit Zero-Knowledge-Proof-Technologie zu generieren, die Kosten immer noch hoch sind und es auch einen Kompromiss zwischen der Kompatibilität von Ethereum und der Leistung von zkevm gibt. Das Polygon-Team gab außerdem zu: „Die Testnet-Version von Polygon zkEVM verfügt auch über begrenzte Durchsatzfähigkeiten, was bedeutet, dass sie noch lange nicht die endgültige Form einer optimierten Skalierungsmaschine erreicht.“
3. Datenverfügbarkeitsschicht
Die abstrakten Ausführungsschritte von Ethereum sind wie folgt:
Im Dezentralisierungsprozess von Ethereum können wir es auch auf der Merge-Roadmap sehen – dezentrale Validatoren. Die wichtigste davon besteht darin, die Vielfalt der Kunden zu berücksichtigen, die Eintrittsschwelle für Maschinen zu senken und die Anzahl der Validatoren zu erhöhen. Wenn daher einige Validatoren, deren Maschinen den Standards nicht entsprechen, am Netzwerk teilnehmen möchten, können sie Light-Knoten verwenden. Das Funktionsprinzip von Light-Knoten besteht darin, Blockheader über nahegelegene Vollknoten anzufordern Blockheader. Wenn Light Nodes nicht teilnehmen, müssen alle Transaktionen von Full Nodes überprüft werden. Daher müssen Full Nodes jede Transaktion im Block herunterladen und verifizieren. Gleichzeitig stehen Full Nodes unter zunehmendem Druck Daher tendiert das Knotennetzwerk nach und nach dazu, leistungsstark und zentralisiert zu sein.
Das Problem hierbei ist jedoch, dass ein böswilliger Vollknoten einen fehlenden/ungültigen Blockheader liefern kann, ein Light-Knoten ihn jedoch nicht fälschen kann. Die erste Möglichkeit besteht darin, einen Betrugsnachweis zu verwenden, der einen vertrauenswürdigen Vollknoten erfordert . Überwachen Sie die Gültigkeit des Blocks und erstellen Sie einen Betrugsnachweis, nachdem Sie einen ungültigen Block entdeckt haben. Wenn der Betrugsnachweis nicht innerhalb eines bestimmten Zeitraums eingeht, wird er als gültiger Blockheader eingestuft. Aber hier brauchen wir natürlich einen vertrauenswürdigen Vollknoten, der vertrauenswürdige Einstellungen oder ehrliche Annahmen erfordert. Der Blockproduzent kann jedoch einige Transaktionen verbergen, und der Betrugsnachweis ist offensichtlich ungültig, da ehrliche Knoten auch auf die Daten des Blockproduzenten angewiesen sind. Wenn die Daten selbst verborgen sind, denken die vertrauenswürdigen Knoten, dass die übermittelten Daten alle sind Daten, dann wird natürlich kein Betrugsnachweis generiert.
In einem von Mustarfa AI-Bassam und Vitalik gemeinsam verfassten Artikel wird eine neue Lösung vorgeschlagen – Erasure Coding. Löschcodes werden verwendet, um Datenverfügbarkeitsprobleme zu lösen. Celestia und Polygon nutzen beispielsweise alle Reed-Solomon-Löschcodes. Aber wie kann sichergestellt werden, dass die übermittelten Daten vollständig sind? Daten können mit KZG-Engagement/Betrugsnachweis kombiniert werden.
Beim KZG-Verpflichtungs-/Betrugsnachweis kann sichergestellt werden, dass der Blockproduzent vollständige Daten veröffentlicht, ohne Transaktionen zu verbergen. Anschließend werden die Daten durch Löschcodierung und anschließend durch Datenverfügbarkeitsstichproben codiert, sodass leichte Knoten die Daten korrekt überprüfen können.
Die vom Aggregator im Rollup übermittelten Daten werden in Form von Anrufdaten in der Kette gespeichert, da Anrufdatendaten günstiger sind als andere Speicherbereiche.
Anrufdatenkosten in Gas = Transaktionsgröße × 16 Gas pro Byte
Die Hauptkosten jeder Transaktion sind die Anrufdatenkosten, da die Speicherung in der Kette extrem teuer ist und dieser Teil bis zu 80 % bis 95 % der Rollup-Kosten ausmacht.
Aufgrund dieses Problems haben wir das neue Transaktionsformat Blob von EIP-4844 vorgeschlagen, um die Blockkapazität zu erweitern und die für die Übermittlung an die Kette erforderliche Gasgebühr zu senken.
4. On-Chain- und Off-Chain-Datenverfügbarkeitsschicht
Wie lässt sich also das Problem teurer Daten in der Kette lösen? Es gibt mehrere Methoden:
Die erste besteht darin, die auf L1 hochgeladene Anrufdatengröße zu komprimieren. In diesem Bereich wurden viele Optimierungen vorgenommen. Die zweite besteht darin, die Kosten für die Speicherung von Daten in der Kette zu senken, durch Ethereums Proto-Danksharding und Danksharding „große Blöcke“ und einen größeren Datenverfügbarkeitsraum bereitzustellen und das Problem der leichten Knoten mithilfe von Löschcodierung und KZG-Engagement zu lösen. Wie EIP-4844. Die dritte besteht darin, die Datenverfügbarkeit außerhalb der Kette zu verlagern. Zu den gängigen Lösungen für diesen Teil gehören Celestia/Polygon-Verfügbarkeit usw.
Je nach Speicherort der Datenverfügbarkeit unterteilen wir sie wie in der folgenden Abbildung dargestellt:
Validiums Lösung: Verlagern Sie die Datenverfügbarkeit außerhalb der Kette, dann werden diese Transaktionsdaten von zentralen Betreibern verwaltet und Benutzer benötigen vertrauenswürdige Einstellungen, aber die Kosten werden sehr niedrig sein, aber gleichzeitig gibt es fast keine Sicherheit. Später schlugen sowohl Starkex als auch Arbitrum Nova die Einrichtung eines DAC vor, der für die Speicherung von Transaktionsdaten verantwortlich sein sollte. DAC-Mitglieder sind Einzelpersonen oder Organisationen, die bekannt sind und sich im rechtlichen Zuständigkeitsbereich befinden, und es wird davon ausgegangen, dass sie nicht zusammenarbeiten und Böses tun.
Zkporter schlägt vor, dass Erziehungsberechtigte (Zksync-Token-Inhaber) sich verpflichten, die Datenverfügbarkeit aufrechtzuerhalten. Wenn ein Datenverfügbarkeitsfehler auftritt, verfallen die zugesagten Mittel. Mit Volition können Benutzer zwischen der Datenverfügbarkeit in der Kette und außerhalb der Kette wählen und je nach Bedarf zwischen Sicherheit und Kosten wählen.
Zu diesem Zeitpunkt erscheinen Celestia und Polygon Avail. Wenn Validium Anforderungen an die Datenverfügbarkeit außerhalb der Kette hat, aber Angst vor einer geringen Dezentralisierung hat, die zu Angriffen mit privaten Schlüsseln ähnlich wie bei Cross-Chain-Brücken führen kann, kann eine dezentrale universelle DA-Lösung dieses Problem lösen. Celestia und Polygon Avail bieten Validium eine Off-Chain-DA-Lösung, indem sie zu einer separaten Kette werden. Durch eine separate Kette wird zwar die Sicherheit verbessert, die Kosten steigen jedoch entsprechend.
Die Erweiterung von Rollup besteht zum einen aus der Ausführungsgeschwindigkeit des Aggregators und zum anderen ist die Zusammenarbeit mit der Datenverfügbarkeitsschicht erforderlich. Derzeit wird davon ausgegangen, dass die Transaktionsausführungsgeschwindigkeit möglich ist erreichen unendlich, dann besteht das Hauptdilemma bei der Erweiterung darin, dass es vom Datendurchsatz der zugrunde liegenden Datenverfügbarkeitslösung beeinflusst wird. Wenn das Rollup seinen Transaktionsdurchsatz maximieren soll, ist es entscheidend, wie der Datenraumdurchsatz der Datenverfügbarkeitslösung maximiert werden kann.
Kehren wir zum Anfang zurück: Nutzen Sie KZG-Engagement oder Betrugsnachweis, um die Datenintegrität sicherzustellen, und verwenden Sie Erasure Coding, um Transaktionsdaten zu erweitern, um Light Nodes bei der Datenverfügbarkeitsstichprobe zu unterstützen und so sicherzustellen, dass Light Nodes Daten korrekt überprüfen können.
Vielleicht möchten Sie sich auch fragen: Wie gewährleistet die KZG-Verpflichtung die Integrität ihrer Daten? Vielleicht kann ich dir eine kleine Antwort geben:
KZG-Verpflichtung: Beweisen Sie, dass der Wert eines Polynoms an einem bestimmten Ort mit einem angegebenen numerischen Wert übereinstimmt. Ein KZG-Commitment ist nichts anderes als eine Art Polynom-Commitment, das in der Lage ist, eine Nachricht zu verifizieren, ohne dass ihm eine bestimmte Nachricht gegeben wird. Der ungefähre Ablauf ist wie folgt:
Wandeln Sie die Daten durch Erasure Coding in Polynome um und erweitern Sie diese. Der Einsatz von KZG verspricht sicherzustellen, dass unsere Erweiterung effektiv ist und die Originaldaten gültig sind. Verwenden Sie dann die Erweiterung, um die Daten zu rekonstruieren, und führen Sie schließlich eine Datenverfügbarkeitsstichprobe durch.
Der Committer generiert ein Commitment und bindet es an die Nachricht. Senden Sie die gebundene Nachricht an den Prüfer. Das Kommunikationsschema hängt hier von der Größe des Nachweises ab. Verifizierer (Verifizierer), mehrere Werte, die in das endliche Feld gebracht werden, überprüfen, ob sie immer noch gleich a sind (dies ist der Prozess der Verfügbarkeitsstichprobe. Das Grundprinzip ist, dass die Wahrscheinlichkeit der Richtigkeit umso höher ist, je mehr Verifizierungszeiten vorhanden sind).
Celestia verlangt von Validatoren, dass sie ganze Blöcke herunterladen, und Danksharding nutzt jetzt Techniken zur Datenverfügbarkeitsstichprobe.
Da Blöcke teilweise verfügbar sind, müssen wir bei der Rekonstruktion von Blöcken jederzeit eine Synchronisierung sicherstellen. Wenn ein Block teilweise verfügbar wird, kommunizieren die Knoten miteinander, um ihn zusammenzusetzen.
Vergleich von KZG-Engagement und Datenbetrugsnachweis:
Es ist ersichtlich, dass KZG verspricht, sicherzustellen, dass die Erweiterung und die Daten korrekt sind, und der Betrugsnachweis einen Dritten zur Beobachtung hinzuzieht. Der offensichtlichste Unterschied besteht darin, dass Betrugsnachweise ein Zeitintervall erfordern, in dem Beobachter reagieren können, bevor Betrug gemeldet wird. Zu diesem Zeitpunkt ist eine direkte Synchronisierung der Knoten erforderlich, damit das gesamte Netzwerk rechtzeitig Betrugsnachweise erhalten kann. KZG ist deutlich schneller als Fraud Proof. Es verwendet mathematische Methoden, um sicherzustellen, dass die Daten korrekt sind, ohne dass eine Wartezeit erforderlich ist.
Es kann beweisen, dass die Daten und ihre Erweiterung korrekt sind. Da das eindimensionale KZG-Engagement jedoch größere Ressourcen erfordert, entscheidet sich Ethereum für das zweidimensionale KZG-Engagement.
Zum Beispiel 100 Zeilen × 100 Spalten, also 100.000 Anteile. Aber jede Probenahme ist keine Eins-zu-10.000-Garantie. Eine vierfache Erweiterung bedeutet also, dass mindestens 1/4 der gesamten Freigabe nicht verfügbar sein muss. Nur dann können Sie eine nicht verfügbare Freigabe zeichnen, was bedeutet, dass sie wirklich nicht verfügbar ist, da sie nicht wiederhergestellt werden kann. Nur wenn 1/4 nicht verfügbar ist und nicht wiederhergestellt werden kann, kann der Fehler wirklich effektiv entdeckt werden, sodass die Wahrscheinlichkeit, einmal zu zeichnen, etwa 1/4 beträgt. Nach mehr als zehn oder fünfzehnmaligem Pumpen kann eine Zuverlässigkeitsgarantie von 99 % erreicht werden. Wählen Sie nun einen Wert zwischen 15 und 20 Mal aus.
5. EIP-4844 (Proto-Danksharding)
In der Proto-Danksharding-Implementierung müssen alle Validatoren und Benutzer weiterhin direkt die Verfügbarkeit der vollständigen Daten überprüfen.
Das von Proto-Danksharding eingeführte Hauptmerkmal ist ein neuer Transaktionstyp, den wir Blob-tragende Transaktionen nennen. Eine Transaktion, die ein Blob enthält, ähnelt einer regulären Transaktion, außer dass sie auch ein zusätzliches Datenelement enthält, das als Blob bezeichnet wird. Blobs sind sehr groß (~125 kB) und viel günstiger als vergleichbare Anrufdatenmengen. Auf diese Blobs kann jedoch nicht über die EVM zugegriffen werden (es gibt nur Zusagen für die Blobs). Und Blobs werden von der Konsensschicht (Beacon-Kette) und nicht von der Ausführungsschicht gespeichert. Dies ist tatsächlich der Beginn der schrittweisen Entwicklung des Konzepts des Data Sharding.
Da Validatoren und Clients immer noch den gesamten Blob-Inhalt herunterladen müssen, beträgt das Datenbandbreitenziel beim Proto-Danksharding 1 MB pro Slot statt der vollen 16 MB. Da diese Daten jedoch nicht mit dem Gasverbrauch bestehender Ethereum-Transaktionen konkurrieren, gibt es dennoch große Skalierbarkeitsgewinne.
Während die Implementierung des vollständigen Shardings (unter Verwendung von Stichproben zur Datenverfügbarkeit usw.) eine komplexe Aufgabe ist und auch nach dem Proto-Danksharding eine komplexe Aufgabe bleibt, ist diese Komplexität in der Konsensschicht enthalten. Sobald Proto-Danksharding eingeführt ist, sind keine weiteren Arbeiten seitens der Kundenteams, Rollup-Entwickler und Benutzer erforderlich, um den Übergang zum vollständigen Sharding abzuschließen. Proto-Danksharding trennt außerdem Blob-Daten von Aufrufdaten, wodurch es für Clients einfacher wird, Blob-Daten in kürzerer Zeit zu speichern.
Es ist erwähnenswert, dass die gesamte Arbeit durch die Konsensschicht geändert wird und keine zusätzliche Arbeit seitens des Kundenteams, der Benutzer oder Rollup-Entwickler erfordert.
Sowohl EIP-4488 als auch Proto-Danksharding führen zu einer langfristigen maximalen Nutzung von etwa 1 MB pro Steckplatz (12 Sekunden). Dies entspricht etwa 2,5 Terabyte pro Jahr, viel mehr als die Wachstumsrate, die Ethereum heute benötigt.
Im Fall von EIP-4488 erfordert die Lösung dieses Problems den Vorschlag zum Ablauf des Verlaufs EIP-4444 (im Abschnitt „Roadmap“ erwähnt), bei dem Clients nicht mehr verpflichtet sind, den Verlauf über einen bestimmten Zeitraum hinaus zu speichern.
6. Datenfragmentierung
Hier werde ich die Themen, die jeder während der Expansion von Ethereum diskutiert, so weit wie möglich aus der Perspektive eines Anfängers erläutern. Kehren wir also zum Sharding zurück und betonen noch einmal das einseitige Konzept des Shardings: Ein einfaches Verständnis ist der Prozess der horizontalen Aufteilung der Datenbank, um die Last zu verteilen.
Hier besteht ein sehr wichtiges Problem bei unserem Daten-Sharding darin, dass in PBS (Antragsteller und Blockersteller sind getrennt, wie in der Roadmap „The Merge“ erwähnt) beim Sharding jede Knotengruppe nur Transaktionen innerhalb des Shards verarbeitet und zwischen den Shards relativ unabhängig ist. Wie sollen also Benutzer A und B einander Geld überweisen, wenn sie sich auf unterschiedlichen Shards befinden? Dann benötigen Sie gute bereichsübergreifende Kommunikationsfähigkeiten.
Der alte Weg bestand darin, die Datenverfügbarkeitsschicht zu fragmentieren, wobei jeder Shard unabhängige Antragsteller und Ausschüsse hatte. Im Validator-Set überprüft jeder Validator abwechselnd die Shard-Daten und lädt alle Daten zur Überprüfung herunter.
Schwäche ist:
Um sicherzustellen, dass Validatoren innerhalb eines Slots synchronisiert werden können, ist eine strenge Synchronisierungstechnologie erforderlich. Validatoren müssen Stimmen aller Gremien einholen, auch hier wird es zu Verzögerungen kommen. Darüber hinaus ist es für den Prüfer auch sehr anstrengend, die Daten vollständig herunterzuladen.
Der zweite Ansatz besteht darin, die vollständige Datenvalidierung aufzugeben und stattdessen einen Stichprobenansatz zur Datenverfügbarkeit zu übernehmen (der später in The Surge implementiert wird). Hier gibt es zwei Zufallsstichprobenmethoden: 1) Block-Zufallsstichprobe, wobei ein Teil der Daten abschnittsweise abgetastet wird. Wenn die Überprüfung erfolgreich ist, signiert der Prüfer. Das Problem dabei ist jedoch, dass es Fälle geben kann, in denen Transaktionen verpasst werden. 2) Interpretieren Sie die Daten durch Löschcodierung in Polynome um und verwenden Sie dann die Eigenschaften von Polynomen, um Daten unter bestimmten Bedingungen wiederherzustellen und die vollständige Verfügbarkeit der Daten sicherzustellen.
Der Schlüssel zum „Sharding“ liegt darin, dass der Validator nicht für das Herunterladen aller Daten verantwortlich ist. Aus diesem Grund wird Proto-Danksharding nicht als „Sharding“ betrachtet (obwohl der Name „Sharding“ enthält). Proto-Danksharding erfordert, dass jeder Validator alle Shard-Blobs vollständig herunterlädt, um ihre Verfügbarkeit zu überprüfen; Danksharding führt dann eine Stichprobenerhebung ein, und ein einzelner Validator muss nur Fragmente von Shard-Blobs herunterladen.
3. Die Zukunft von Ethereum: Schicht 3
Die ZK-Serie Layer 2, die als zukünftige Erweiterung von Ethereum gilt, wie zksync und starknet, haben alle das Konzept von Layer 3 vorgeschlagen. Ein einfaches Verständnis ist Schicht 2 von Schicht 2.
Die hohen Transaktionskosten auf Ethereum zwingen es (L3), zur Abwicklungsschicht für L2 zu werden. Es wird davon ausgegangen, dass Endbenutzer in naher Zukunft aufgrund deutlich niedrigerer Transaktionskosten, zunehmender Unterstützung für DeFi-Tools und erhöhter Liquidität durch L2 die meisten ihrer Aktivitäten auf L2 durchführen werden, wobei Ethereum nach und nach zur Abwicklungsschicht wird.
L2 verbessert die Skalierbarkeit, indem es die Gaskosten pro Transaktion senkt und die Transaktionsraten erhöht. Gleichzeitig behält L2s die Vorteile der Dezentralisierung, der universellen Logik und der Zusammensetzbarkeit bei. Einige Anwendungen erfordern jedoch spezifische Anpassungen, die möglicherweise besser durch eine neue unabhängige Ebene unterstützt werden: L3!
L3 ist mit L2 verknüpft, genauso wie L2 mit L1 verknüpft ist. Solange L2 Verifier Smart Contracts unterstützen kann, kann L3 mithilfe von Gültigkeitsnachweisen implementiert werden. Wenn L2 auch an L1 übermittelte Gültigkeitsnachweise verwendet, wie dies bei StarkNet der Fall ist, entsteht eine sehr elegante rekursive Struktur, bei der die Komprimierungsvorteile von L2-Beweisen mit den Komprimierungsvorteilen von L3-Beweisen multipliziert werden. Wenn jede Schicht beispielsweise eine 1000-fache Kostenreduzierung erreichen würde, könnte L3 theoretisch 1.000.000-mal günstiger sein als L1 – und gleichzeitig die Sicherheit von L1 beibehalten. Dies ist auch ein echter Anwendungsfall für die rekursiven Beweise, auf die Starknet stolz ist.
Hier ist ein Teil des Wissens über „On-Chain und Off-Chain der Datenverfügbarkeitsschicht“ erforderlich. Die gesamte Schicht 3 umfasst:
Rollup (Datenverfügbarkeit in der Kette), Gültigkeit (Datenverfügbarkeit außerhalb der Kette). Die beiden Typen entsprechen unterschiedlichen Anwendungsanforderungen. Web2-Unternehmen, die sensibel auf Preise und Daten reagieren, können Validium verwenden, um Daten außerhalb der Kette zu platzieren, was die Gaskosten in der Kette erheblich senkt und Datenschutz ohne Offenlegung von Benutzerdaten erreichen kann, sodass Unternehmen ihre Daten mithilfe benutzerdefinierter Datenformate vollständig kontrollieren können. Bisherige Unternehmensdaten-Geschäftsmodelle können weiterhin reibungslos funktionieren.
L2 ist für Erweiterungen und L3 für benutzerdefinierte Funktionen wie Datenschutz vorgesehen.
In dieser Vision wird nicht versucht, „quadratische Skalierbarkeit“ bereitzustellen; stattdessen gibt es eine Ebene im Stapel, die die Skalierung von Anwendungen unterstützt, und dann werden die Ebenen basierend auf benutzerdefinierten Funktionsanforderungen für verschiedene Anwendungsfälle getrennt.
L2 ist für allgemeine Erweiterungen und L3 für benutzerdefinierte Erweiterungen vorgesehen.
Benutzerdefinierte Erweiterungen können in verschiedenen Formen vorliegen: spezialisierte Anwendungen, die für die Berechnung etwas anderes als die EVM verwenden, Rollups, deren Datenkomprimierung für das anwendungsspezifische Datenformat optimiert ist (einschließlich der Trennung von „Daten“ von „Beweisen“) und den Beweis vollständig durch ersetzen ein einzelner SNARK pro Block) usw.
L2 wird für die vertrauenswürdige Erweiterung (Rollup) und L3 für die schwache Vertrauenserweiterung (Validium) verwendet.
Validium ist ein System, das SNARKs zur Überprüfung von Berechnungen verwendet, die Datenverfügbarkeit jedoch einem vertrauenswürdigen Dritten oder Gremium überlässt. Meiner Meinung nach wird Validium ernsthaft unterschätzt: Insbesondere viele „Enterprise-Blockchain“-Anwendungen werden möglicherweise am besten von einem zentralen Server bedient, auf dem ein Validium-Prover läuft und regelmäßig Hashes an die Kette sendet. Validium ist weniger sicher als Rollup, kann aber viel günstiger sein.
Für dApp-Entwickler gibt es mehrere Optionen für die Infrastruktur:
Entwickeln Sie selbst ein Rollup (ZK-Rollups oder Optimistic Rollups)
Der Vorteil besteht darin, dass Sie das Ethereum-Ökosystem (Benutzer) und seine Sicherheit erben können, aber für ein dApp-Team sind die Entwicklungskosten von Rollup offensichtlich zu hoch.
Wählen Sie Cosmos, Polkadot oder Avalanche
Die Entwicklungskosten werden niedriger sein (dydx hat sich beispielsweise für Cosmos entschieden), aber Sie verlieren das Ethereum-Ökosystem (Benutzer) und die Sicherheit.
Entwickeln Sie Ihre eigene Layer-1-Blockchain
Die damit verbundenen Entwicklungskosten und -schwierigkeiten sind sehr hoch, aber es kann die höchste Kontrolle haben.
Vergleichen wir drei Situationen:
Schwierigkeit/Kosten: Alt-Layer 1 > Rollup > Cosmos Sicherheit: Rollup > Cosmos > Alt-Layer 1 Ökologie/Benutzer: Rollup > Cosmos > Alt-Layer 1 Steuerung: Alt-Layer 1 > Cosmos > Rollup
Wenn Sie als dApp-Entwickler die Sicherheit und den Datenverkehr von Ethereum erben möchten, können Sie keine Kette neu entwickeln und nur Rollup wählen. Da es jedoch sehr teuer ist, ein Layer-2-Rollup selbst zu entwickeln, besteht die geeignete Lösung darin, das Layer-3-SDK zu verwenden, um ein anwendungsspezifisches Rollup (anwendungsspezifisches Rollup), also Layer 3, zu entwickeln.
4. Zukünftige Entwicklung von Layer 2
Da Ethereum auf dem Kontomodell basiert, befinden sich alle Benutzer in einem gesamten Statusbaum, sodass keine Parallelität möglich ist. Daher erfordern die Fesseln von Ethereum selbst, dass es Ausführungsvorgänge ablöst und mehrere Rollup-Transaktionen zu einer einzigen Transaktion zusammenfasst eine Siedlungsschicht. Alle Probleme konzentrieren sich nun auf die Verbesserung des Durchsatzes der Schicht 2. Die Verwendung von Layer 3 kann nicht nur den Transaktionsdurchsatz verbessern, sondern auch die Implementierung der Parallelverarbeitung auf Layer 2 kann den Durchsatz des gesamten Netzwerks erheblich verbessern.
Das Problem der Parallelisierung wird von Starknet ebenfalls aktiv untersucht. Obwohl der aktuelle Beweisalgorithmus immer noch eine Fessel darstellt, wird erwartet, dass er in Zukunft kein Hindernis darstellen wird. Mögliche Engpässe sind:
Sortierer-Sendeabwicklung: Einige Sortieraufträge scheinen von Natur aus seriell zu sein. Bandbreite: Verbindungen zwischen mehreren Sequenzern sind begrenzt. L2-Zustandsgröße
In der Starknet-Community wiesen Mitglieder auch darauf hin, dass die Parallelverarbeitungsmethode von Aptos sehr gut sei. Starknet seinerseits treibt derzeit auch die Möglichkeit voran, eine parallele Sendesortierung innerhalb des Sortierers durchzuführen.
5. Zusammenfassung
Ethereum entfernt die Ausführungsebene und richtet alles auf seine Vision einer „globalen“ Abwicklungsebene aus. Obwohl sich das gesamte Ethereum derzeit nur langsam weiterentwickelt, liegt das daran, dass es insgesamt zu groß ist und jede Aktualisierung viele Interessen und Kompromisse mit sich bringt. Es ist jedoch nicht zu leugnen, dass Ethereum große Veränderungen in der Kette durchläuft, Verbesserungen der Wirtschaftsmechanismen und die Skalierbarkeit von Ethereum 2.0. Es führt zu innovativen ICOs, Defi, NFT und vielen anderen Dingen, die der Aufregung würdig sind Aufregung der Ethereum-Community. Ich glaube, dass Ethereum in naher Zukunft wirklich in der Lage sein wird, seine große Vision zu verwirklichen, da immer mehr Länder Ethereum-Knoten einsetzen, zum Beispiel plant die argentinische Hauptstadtregierung, im Jahr 2023 Ethereum-Verifizierungsknoten einzusetzen.