Wir stellen Eclipse Mainnet vor: Die Ethereum SVM L2

Fortgeschrittene12/6/2023, 1:59:29 PM
In diesem Artikel werden die Unterschiede zwischen Eclipse und der aktuellen Rollup-Technologie aus mehreren Perspektiven erläutert, die Kombination von Vorteilen wie SVM, DAS-Light-Nodes, RISC-Zero-Knowledge-Proofs hervorgehoben und MetaMask Snaps für nahtlose Übergänge eingesetzt.

Eclipse Mainnet ist ein Allzweck-L2, das die besten Teile des modularen Stacks kombiniert:

  1. Abwicklung: Ethereum – Eclipse wird sich an Ethereum orientieren (dh die verankerte Validierungsbrücke wird sich auf Ethereum befinden) und ETH als Gas-Token verwenden.
  2. Ausführung: Solana Virtual Machine (SVM) – Eclipse führt die hochleistungsfähige SVM als Ausführungsumgebung aus.
  3. Datenverfügbarkeit: Celestia – Eclipse wird seine Daten zur skalierbaren Datenverfügbarkeit (DA) an Celestia veröffentlichen.
  4. Beweisen: RISC Zero – Eclipse wird RISC Zero für ZK-Betrugsnachweise verwenden (ohne Zwischenzustandsserialisierung!)

Die meisten Schlagzeilen von Eclipse drehten sich um unsere Arbeit, anwendungsspezifische Rollups für eine Reihe von Projekten bereitzustellen, aber jetzt ist klarer denn je, dass Ethereum einen Allzweck-L2 benötigt, der wirklich enorm skalierbar ist. Die meisten Anwendungen profitieren nicht von anwendungsspezifischen Kettenanpassungen, und die daraus resultierende Isolation und Komplexität kann tatsächlich zu einer schlechteren UX- und Entwicklererfahrung führen.

Oft wird eine falsche Dichotomie zwischen der modularen Rollup-Vision und der Möglichkeit einer einzigen Kette mit massiver Skalierung, parallelisierter Ausführung und gemeinsamem Status dargestellt . „Modular“ wird oft mit „App-spezifisch“ verwechselt, was den Eindruck erwecken würde, dass Rollups eine Welt mit vielen fragmentierten Ketten mit geringem Durchsatz bedeuten. Wir stellen diese Idee in Frage.

Ausführung: Solanas Geschwindigkeit und Größe

Eclipse Mainnet wird die erstklassige Ausführungsumgebung von Solana übernehmen. Das bringt enorme Vorteile:

Optimierte parallele Ausführung

Die SVM und ihre Sealevel-Laufzeit ermöglichen bekanntermaßen die parallele Transaktionsausführung. Transaktionen, die keinen überlappenden Status berühren, können parallel statt sequentiell ausgeführt werden.

Dadurch kann die SVM direkt mit der Hardware skaliert werden, da Prozessoren weiterhin mehr Kerne zu geringeren Kosten hinzufügen. Single-Threaded-Laufzeiten (wie das heutige EVM) profitieren grundsätzlich nicht von der Reduzierung der Kosten pro Kern. Seit über einem Jahrzehnt nehmen die Leistungssteigerungen durch Single-Threaded kontinuierlich ab. Fast alle Verbesserungen ergeben sich weiterhin aus der Erhöhung der Anzahl der Kerne. Daher ist es wichtig, diesen Trend durch Parallelisierung der Arbeitslasten zu nutzen:

Es gibt einige sehr frühe, unbewiesene Versuche, die EVM zu parallelisieren, aber das Hinzufügen dieser unter Beibehaltung der Kompatibilität bringt grundlegende Kompromisse mit sich, einschließlich suboptimaler Leistung, ohne andere Engpässe (z. B. Zustandswachstum) zu beheben. Verträge, die Zustandsabhängigkeiten im Voraus deklarieren (wie in der SVM), ermöglichen eine optimale Parallelisierung.

Lokale Gebührenmärkte

Die meisten Gebührenmärkte sind heutzutage global, was bedeutet, dass eine heiße Anwendung die Gebühren für alle Benutzer der Kette erhöht. Ein NFT-Mint sollte die Kette nicht für alles andere unbrauchbar machen. Solanas großartige Arbeit zu lokalen Gebührenmärkten löst diesen app-staatenübergreifenden Streit. In seiner aktuellen Implementierung priorisiert der Scheduler Transaktionen ohne Konflikte, sodass konfliktfreie Transaktionen mit geringeren Gebühren durchgeführt werden können. Längerfristig werden lokale Gebührenmärkte auf Protokollebene implementiert. Dadurch wird sichergestellt, dass sich Gebührenspitzen für eine einzelne App nicht auf den Rest der Kette auswirken.

Dank der einzigartig parallelisierten Laufzeit von Solana sind lokale Gebührenmärkte möglich. Der Versuch, lokale Gebührenmärkte für staatliche Hotspots im EVM mithilfe von Heuristiken zu implementieren (dh ohne den staatlichen Zugriff im Voraus zu deklarieren), würde Ineffizienzen und wahrscheinliche Angriffsvektoren mit sich bringen.

Es gibt auch erste Forschungsarbeiten , die es Anwendungen ermöglichen würden, den ihnen zugeschriebenen lokalen Wert leicht zu verinnerlichen, was heute im Allgemeinen ein kreativeres Design auf App-Ebene erfordert.

Staatliches Wachstumsmanagement

Bevor die EVM überhaupt auf die sequentielle Ausführung als Engpass stößt, ist das Zustandswachstum ihr weitaus dringlicherer Engpass.

Da es keinen Merkle-Baum für den Bundesstaat gibt, entsteht bei Solana nicht der Aufwand für die Aktualisierung eines Merkle-Baums für jede Statusaktualisierung. Stattdessen wird nach jeder Epoche (~2,5 Tage) der gesamte Zustand merklisiert. Dies ist viel günstiger als die Merklisierung in Echtzeit (wie im EVM).

Noch wichtiger ist, dass die EVM über einen dynamischen Kontozugriff verfügt (dh Transaktionen können bei Bedarf jeden Status berühren). Diese dynamische Statussuche bedeutet, dass dieser Status vor der Ausführung nicht in den Speicher geladen werden kann. In der SVM gibt jede Transaktion den gesamten Status an, der für die Ausführung erforderlich ist.

Daher hat die Statusgröße keinen Einfluss auf die SVM-Ausführung. Unter der Annahme, dass Validatoren ihre Speicherfestplatten alle zwei Jahre aktualisieren, könnte das Netzwerk die Snapshot-Größe sicher alle zwei Jahre verdoppeln, ohne auf größere Probleme zu stoßen.

Darüber hinaus verbessern Teams wie Helius aktiv die Zugänglichkeit historischer Daten und reduzieren die Zustandsgröße durch Komprimierung.

EVM-Kompatibilität

Neon EVM ist ein EVM, das als Smart Contract fungiert und in jeder SVM-Kette bereitgestellt werden kann. Dies bringt volle EVM-Kompatibilität mit Eclipse Mainnet (einschließlich EVM-Bytecode-Unterstützung und dem Ethereum JSON-RPC) mit höherem Durchsatz als Single-Threaded-EVMs. Da jede Neon-EVM-Instanz über einen eigenen lokalen Gebührenmarkt verfügt, können Apps einfach ihren eigenen Vertrag bereitstellen, um die Vorteile einer App-Kette zu nutzen, ohne UX, Sicherheit oder Liquidität zu fragmentieren.

Unabhängig davon ermöglicht der Solang- Compiler die Kompilierung von Solidity-Smart-Contracts-Code in SVM-Bytecode.

MetaMask-Snaps

Das Onboarding von EVM-Benutzern in Nicht-EVM-Ketten war in der Vergangenheit eine große Hürde, aber die kürzlich vorgestellten Metamask Snaps sollen diese Hürde überwinden. EVM-Benutzer können MetaMask weiterhin verwenden, ohne die Wallet wechseln zu müssen. Dank der Open-Source-Beiträge von Driftzum Aufbau einer großartigen MetaMask Snap-Implementierung ist die UX mit der Interaktion mit jeder EVM-Kette vergleichbar. Eclipse-Mainnet-Benutzer können nativ in MetaMask mit Apps interagieren oder eine Solana-native Wallet wie Salmon verwenden.

Hier ist ein kleiner Vorgeschmack auf die UX von Drift:

Feuertänzer

Firedancer ist der mit Spannung erwartete Solana-Client, der von Jump entwickelt wird, um den Durchsatz, die Widerstandsfähigkeit und die Effizienz des Netzwerks drastisch zu steigern. Beim Start werden wir uns so nah wie möglich an den Solana-Kernclient halten, aber wir planen, Firedancer zu übernehmen, sobald der Code live und stabil ist.

Sicherheit

Die Laufzeit von Solana verfügt über eine stark reduzierte Angriffsfläche, was die berüchtigten Wiedereintritts-Exploits verhindert, die wir viel zu oft gesehen haben. Konkret erlaubt die Solana-Laufzeitprogrammen nur die Selbstrekursion von Programmen, statt willkürliche reentrante programmübergreifende Aufrufe zuzulassen. Darüber hinaus führt die Trennung von Status und Code zu zustandslosem Code, der sich in der Regel einfacher und effektiver testen lässt.

Einfachere Prüfung

Die SVM ist registerbasiert und verfügt im Vergleich zur EVM über einen viel kleineren Befehlssatz, wodurch sich die SVM-Ausführung in ZK einfacher nachweisen lässt. Bei optimistischen Rollups ermöglicht das registerbasierte Design ein einfacheres Checkpointing.

Abwicklung: Sicherheit und Liquidität von Ethereum

Wie bei den heutigen großen Rollups wird sich das Eclipse Mainnet auf Ethereum niederlassen. Konkret bedeutet dies, dass unsere Validierungsbrücke auf Ethereum direkt in Eclipse verankert wird. Eclipse-Knoten greifen auf diese Brücke zurück, um die „kanonische Kette“ zu bestimmen. Die Bridge erzwingt die korrekte Reihenfolge für Eclipse.

Dadurch können unsere Nutzer bestimmte Sicherheitseigenschaften von Ethereum erhalten. Die Bridge validiert alle Eclipse-Transaktionen und verhindert so die Übermittlung ungültiger Zustände. Darüber hinaus wird es in bestimmten Fehlerfällen eine eventuelle Liveness und Zensurresistenz erzwingen. Selbst wenn der Sequenzer ausfallen oder auf L2 zensieren würde, könnten Benutzer die Einbeziehung ihrer Transaktionen über die Brücke erzwingen.

Aufgrund dieser Sicherheitseigenschaften werden Validium und Optimium oft als „Ethereum L2s“ bezeichnet. L2BEAT definiert einen L2 als „eine Kette, die ihre Sicherheit ganz oder teilweise von Layer-1-Ethereum ableitet, sodass Benutzer sich für die Sicherheit ihrer Gelder nicht auf die Ehrlichkeit von L2-Validatoren verlassen müssen.“

Die Ethereum-Vereinbarung erkennt die Bedeutung an, die native Vermögenswerte von Ethereum wahrscheinlich in der DeFi- und NFT-Wirtschaft von Eclipse Mainnet spielen werden. ETH ist das beste dezentrale Geld, das die meisten Benutzer eindeutig bevorzugen, daher werden wir ETH auch als unseren Gas-Token verwenden. Längerfristig wird die Gebührenabstraktion es Benutzern ermöglichen, mit jedem beliebigen Token ihrer Wahl (z. B. USDC) zu bezahlen. Derzeit ist nicht geplant, dass Eclipse Mainnet über einen eigenen Token verfügt.

Datenverfügbarkeit: Bandbreite und Überprüfbarkeit von Celestia

Eclipse Mainnet wird Celestia für die Datenverfügbarkeit nutzen (auch bekannt als: Datenveröffentlichung oder Datenveröffentlichung). Celestia ist ein langjähriger Ökosystempartner von Eclipse.

Der angestrebte Durchsatz und die Gebühren des Eclipse Mainnet werden von der aktuellen Bandbreite von Ethereum leider nicht unterstützt. Dies wird auch nach EIP-4844 (aka „Proto-danksharding“), das durchschnittlich ~0,375 MB Blobspace pro Block bereitstellt (mit einem Limit von ~0,75 MB pro Block).

  1. Für ERC-20-Übertragungen mit Basiskomprimierung (~154 Bytes pro Transaktion) entspricht dies über alle Rollups zusammengenommen etwa 213 TPS.
  2. Bei Swaps mit Komprimierung (ca. 400 Byte pro Transaktion) entspricht dies ca. 82 TPS über alle Rollups hinweg zusammen.

Im Vergleich dazu wird Celestia später in diesem Jahr mit 2-MB-Blöcken starten. Es wird erwartet, dass Blobspace kurz nach dem Start auf 8 MB ansteigt, sobald genügend Data Availability Sampling (DAS) -Lichtknoten online sind und sich das Netzwerk als stabil erweist. DAS-Lichtknoten erfüllen zwei wichtige Funktionen:

  1. Ermöglichen Sie Benutzern, selbst zu überprüfen, ob Eclipse-Blockdaten verfügbar gemacht wurden
  2. Tragen Sie zur sicheren Skalierung des gesamten Netzwerks bei, da DA-Schichten ihren Durchsatz sicher erhöhen können, wenn mehr DAS-Light-Knoten online gehen

Celestia wird voraussichtlich der erste DA-Layer sein, der DAS in Produktion bringt. Dies steht im Gegensatz zu herkömmlichen Data Availability Committees (DACs), die die Ehrlichkeitsannahmen der Komitees ohne Benutzerüberprüfung wieder einführen (ähnlich wie bei bestehenden monolithischen Blockchains).

Es gibt eine inhärente Sicherheitsannahme für Benutzer, die ihre Gelder vom Ethereum Mainnet auf jede Kette übertragen, die Off-Chain-DA verwendet. Insbesondere ist es Celestia-Validatoren technisch möglich, Transaktionsdaten zurückzuhalten, gegenüber der Ethereum-Brücke jedoch zu behaupten, dass die Daten verfügbar seien. In der Praxis bedeutet der Proof-of-Stake-Konsens von Celestia, dass die Zurückhaltung von Daten zu Celestia selbst drastisch reduziert werden kann, was dieses Risiko unserer Meinung nach unrealistisch macht.

Insgesamt machen Celestias DAS-Light-Node-Unterstützung vom ersten Tag an, kryptoökonomische Sicherheitseigenschaften und der hoch skalierbare DA-Durchsatz es heute zur klaren Wahl für Eclipse Mainnet.

Beachten Sie, dass einige die On-Chain-Ethereum-DA aus den oben beschriebenen Gründen als eine Voraussetzung ansehen, um hier ein echter „L2“ zu sein . Wir orientieren uns an der weiter oben genannten gebräuchlicheren L2-Terminologie und möchten die Sicherheitsaspekte klarstellen.

Wir beabsichtigen auch, die Fortschritte von Ethereum bei der DA-Skalierung nach EIP-4844 zu überwachen. Es kommen immer wieder spannende neue Forschungsergebnisse auf den Markt, die möglicherweise früher als frühere Ideen (die fortschrittlichere verteilte Hash-Tabellen verwenden) einen DA mit hohem Durchsatz bieten können. Wenn Ethereum zum Nutzen unserer Benutzer eine größere Skalierung für Eclipse bietet, würden wir die Möglichkeit einer Migration auf Ethereum DA prüfen.

Beweisen: RISC Zero ZK-Beweisnachweise für Betrug (ohne Zwischenstatus-Serialisierung!)

Unsere Prüfung wird ähnlich aussehen wie Anatolys SVM-Betrugsnachweise SIMD, was wiederum John Adlers Einsicht ähnelt, dass die staatliche Serialisierung teuer ist und dass es möglich ist, sie zu vermeiden.

Insbesondere möchten wir vermeiden, dass wieder ein Merkle-Baum in die SVM eingeführt wird. Wir haben schon früh damit experimentiert, einen Sparse-Merkle-Baum in die SVM einzufügen, aber die Aktualisierung des Merkle-Baums nach jeder Transaktion führt zu erheblichen Leistungseinbußen. Der Nachweis ohne Merkle-Baum schließt bestehende generalistische Rollup-Frameworks wie den OP-Stack als Grundlage für SVM-Rollups aus und erfordert außerdem eine kreativere fehlersichere Architektur.

Auf hohem Niveau erfordert ein Fehlernachweis:

  1. Eine Verpflichtung zu Eingaben für eine Transaktion,
  2. Die Transaktion selbst und
  3. Beweis, dass die erneute Ausführung der Transaktion zu einer anderen Ausgabe führt als der, die in der Kette angegeben wurde.

Die Eingabezusage erfolgt in der Regel durch die Bereitstellung der Merkle-Wurzel für den Statusbaum des Rollups. Unser Ausführender wird stattdessen eine Liste der Ein- und Ausgaben (einschließlich Konto-Hashes und des relevanten globalen Status) für jede Transaktion veröffentlichen, zusammen mit einem Index der Transaktion, die jede Eingabe erzeugt hat. Die Transaktionen werden in Celestia veröffentlicht, sodass jeder vollständige Knoten mitmachen kann, um Eingabekonten aus seinem eigenen Status abzurufen, die Ausgabekonten zu berechnen und zu bestätigen, dass die Verpflichtung zu Ethereum korrekt ist.

Es gibt zwei mögliche Arten schwerwiegender Fehler:

  1. Falsche Ausgaben – In diesem Fall liefert der Verifizierer einen ZK-Beweis in der Kette der korrekten Ausgaben. Wir verwenden RISC Zero, um ZK-Beweise der SVM-Ausführung zu erstellen und setzen damit unsere bisherige Arbeit zum Nachweis der BPF-Bytecode-Ausführung fort. Dadurch kann unser Abwicklungsvertrag die Korrektheit sicherstellen, ohne dass die Transaktionen selbst in der Kette ausgeführt werden müssen.
  2. Falsche Eingaben – In diesem Fall veröffentlicht der Verifizierer in der Kette einen Verweis auf die historischen Daten, aus dem hervorgeht, dass der Eingabestatus nicht den Angaben entspricht. Mithilfe der Quantengravitationsbrücke von Celestia stellt unser Vergleichsvertrag sicher, dass diese historischen Daten tatsächlich einen Betrug beweisen.

Warum Eclipse, warum Ethereum, warum jetzt

Wir stehen auf den Schultern von Riesen. Die heutigen Rollups haben den Forschungsstand für unsere gesamte Branche vorangebracht und Ethereum-Benutzern im Vergleich zu L1 günstigere Gebühren beschert.

Sie nutzen jedoch nicht alle Vorteile der neuesten Technologie aus, die für die Massentauglichkeit erforderlich ist. Frühe Rollups legten großen Wert auf EVM-Kompatibilität und/oder Optimierungen für eine effizientere ZK-Prüfung. In jüngerer Zeit haben wir jedoch unglaubliche Fortschritte gesehen, die die Notwendigkeit, diese Kompromisse einzugehen, die bei frühen Rollups beschlossen wurden, überflüssig machen und sie tatsächlich benachteiligen:

  1. Hochperformante parallelisierte VMs (z. B. SVM)
  2. DA-Skalierung mit DAS-Light-Node-Unterstützung (z. B. Celestia)
  3. Fortschritte in der Proof-Infrastruktur, um sie überall praktikabel zu machen (z. B. RISC Zero)
  4. Erhöhte Portabilität von Code (z. B. Neon und Solang) und Benutzern (z. B. MetaMask Snaps) über Ökosysteme hinweg

Eclipse hat den enormen Vorteil der Rückschau. Wir können aus den Einschränkungen lernen, mit denen andere Ketten konfrontiert waren, und dann die besten Stücke auswählen, um sie langfristig zu skalieren.

https://twitter.com/0xMert?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680271128537726976%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

https://twitter.com/colludingnode?refsrc=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680285353662468097%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

Wir hören oft von einer Zukunft mit einer Million App-spezifischen Rollups.

Anpassungen auf Konsensebene können für bestimmte Anwendungen (z. B. dYdX v4) unglaublich wertvoll sein, und wir freuen uns, Teams bei der Einführung anwendungsspezifischer Rollups zu unterstützen.

Allerdings sind diese Fälle selten. Aus diesem Grund sind die meisten neuen Rollups immer noch nur Vanilla-EVM-Forks. Die Probleme der Entwickler werden nicht durch die Fragmentierung von UX auf mehrere Ketten gelöst. Der Hauptanwendungsfall für eine Million Ketten scheint heute oft die Einführung einer Million weiterer Token zu sein. Für die überwiegende Mehrheit der Anwendungsfälle besteht heute einfach keine Nachfrage nach einer vollständigen Anpassung.

Selbst wenn die tatsächliche Nachfrage vorhanden wäre, wird die Infrastruktur, die zur Unterstützung vieler App-Ketten mit wettbewerbsfähiger UX erforderlich ist, noch Jahre entfernt sein (falls sie jemals den gleichen Wert erreicht). Die Superchain (OP Stack) von Optimism, die Hyperchains (ZK Stack) von zkSync, die Orbit-Ketten von Arbitrum usw. haben alle Visionen für viele Ketten mit gemeinsamer Infrastruktur. Dies soll einen reibungsloseren UX-Betrieb zwischen Ketten im selben Ökosystem (z. B. zwischen zwei Ketten innerhalb der Superchain) im Vergleich zu vollständig isolierten Ketten (z. B. zwischen Ethereum und Solana) ermöglichen.

Allerdings sind die aktuellen Pläne (sofern vorhanden) noch weit davon entfernt, jemals mit einem einzigen gemeinsamen Staat konkurrenzfähig zu sein. Darüber hinaus befassen sie sich nicht mit der Interoperabilität zwischen Ökosystemen (z. B. Superchain zu Hyperchain). Modular zu bauen sollte nicht bedeuten, Inseln zu bauen.

Für Benutzer ist es komplizierter, Konten über viele Ketten hinweg zu verwalten. Es ist noch schlimmer, UX ständig zu überbrücken und sich Gedanken darüber zu machen, welchen Gas-Token Sie benötigen. Es ist komplizierter und teurer, für den Betrieb und die Wartung so vieler Ketten auf Infrastrukturanbieter angewiesen zu sein.

Wir haben die Einfachheit von Solanas Vision immer geschätzt. Eine hochoptimierte gemeinsame Zustandsmaschine mit der Skalierung, die die meisten wertvollen Anwendungsfälle unterstützt. Dies wird oft als unvereinbar mit einer Rollup-zentrierten Roadmap angesehen, aber das ist einfach nicht der Fall. Wir wollen das Beste aus beiden Welten vereinen.

Dieses Missverständnis entsteht aufgrund der Tatsache, dass die heutigen Rollups die Vanilla-Single-Threaded-EVM weitgehend unverändert ausführen, um frühe Netzwerkeffekte zu nutzen. Daher sehen wir häufig „dedizierten Blockraum“ als Grund für die Bereitstellung eines App-spezifischen Rollups. Diese verrückten NFT-Mints sollten nicht die Preise für alle anderen Apps in Ihrer Kette in die Höhe treiben, aber die Antwort ist nicht, eine eigene Kette zu gründen. Das ist, als würde man mit einem Vorschlaghammer eine Erdnuss knacken. Sie gehen schmerzhafte und unnötige Kompromisse ein (Komplexität, Kosten, schlechtere UX, fragmentierte Liquidität usw.). Die optimale Lösung ist unglaublich klar: Verwenden Sie einfach eine parallelisierte VM mit lokalen Gebührenmärkten für staatliche Hotspots. Genau das bringt die SVM.

Ethereum ist das intellektuelle, soziale und wirtschaftliche Zentrum der Kryptowährung. Seine Achillesferse ist gewachsen. Die DA-Skalierung ist noch in Arbeit und die bestehenden L2-Ausführungsumgebungen können nicht mit neueren Innovationen wie der SVM konkurrieren. Wir befürchten, dass das Ethereum-Ökosystem in seiner jetzigen Form von einem starken Anstieg der Aktivität auf dem falschen Fuß erwischt würde. Single-Threaded-EVMs und eingeschränkte DA würden schnell zu einem Wiederaufleben hoher Gebühren führen, außer diesmal bei Rollups.

Wir glauben, dass Eclipse Mainnet die offensichtliche Lösung ist: Es vereint die Leistung von Solana mit der Sicherheit, Überprüfbarkeit und den Netzwerkeffekten der Rollup-zentrierten Roadmap.

Abschiedsgedanken

Das Schöne an Ethereum ist, dass es Innovationen frisst. Die Rollup-zentrierte Roadmap ist der Inbegriff dafür und delegiert Umsetzung und Innovation an den freien Markt. L2s verfügen über die unglaubliche Fähigkeit, die Netzwerkeffekte und Abwicklungsgarantien von Ethereum zu nutzen und gleichzeitig mit den besten neuen Ausführungsumgebungen zu experimentieren. Eclipse Mainnet ist die natürliche Erfüllung dieser Vision.

Wenn eines Tages eine leistungsfähigere Ausführungsschicht hinzukommt, werden wir uns riesig freuen, sie als wettbewerbsfähiges Ethereum L2 einzusetzen. Bis dahin bleibt die SVM der Standard.

Um mitzumachen, wenden Sie sich anhttp://mailto:team@eclipse.builders/team@eclipse.builders, um Testnet-Anweisungen zu erhalten.

Haftungsausschluss:

  1. Dieser Artikel wurde von [Mirror] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Eclipse]. Wenn Sie Einwände gegen diesen Nachdruck haben, 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.

Wir stellen Eclipse Mainnet vor: Die Ethereum SVM L2

Fortgeschrittene12/6/2023, 1:59:29 PM
In diesem Artikel werden die Unterschiede zwischen Eclipse und der aktuellen Rollup-Technologie aus mehreren Perspektiven erläutert, die Kombination von Vorteilen wie SVM, DAS-Light-Nodes, RISC-Zero-Knowledge-Proofs hervorgehoben und MetaMask Snaps für nahtlose Übergänge eingesetzt.

Eclipse Mainnet ist ein Allzweck-L2, das die besten Teile des modularen Stacks kombiniert:

  1. Abwicklung: Ethereum – Eclipse wird sich an Ethereum orientieren (dh die verankerte Validierungsbrücke wird sich auf Ethereum befinden) und ETH als Gas-Token verwenden.
  2. Ausführung: Solana Virtual Machine (SVM) – Eclipse führt die hochleistungsfähige SVM als Ausführungsumgebung aus.
  3. Datenverfügbarkeit: Celestia – Eclipse wird seine Daten zur skalierbaren Datenverfügbarkeit (DA) an Celestia veröffentlichen.
  4. Beweisen: RISC Zero – Eclipse wird RISC Zero für ZK-Betrugsnachweise verwenden (ohne Zwischenzustandsserialisierung!)

Die meisten Schlagzeilen von Eclipse drehten sich um unsere Arbeit, anwendungsspezifische Rollups für eine Reihe von Projekten bereitzustellen, aber jetzt ist klarer denn je, dass Ethereum einen Allzweck-L2 benötigt, der wirklich enorm skalierbar ist. Die meisten Anwendungen profitieren nicht von anwendungsspezifischen Kettenanpassungen, und die daraus resultierende Isolation und Komplexität kann tatsächlich zu einer schlechteren UX- und Entwicklererfahrung führen.

Oft wird eine falsche Dichotomie zwischen der modularen Rollup-Vision und der Möglichkeit einer einzigen Kette mit massiver Skalierung, parallelisierter Ausführung und gemeinsamem Status dargestellt . „Modular“ wird oft mit „App-spezifisch“ verwechselt, was den Eindruck erwecken würde, dass Rollups eine Welt mit vielen fragmentierten Ketten mit geringem Durchsatz bedeuten. Wir stellen diese Idee in Frage.

Ausführung: Solanas Geschwindigkeit und Größe

Eclipse Mainnet wird die erstklassige Ausführungsumgebung von Solana übernehmen. Das bringt enorme Vorteile:

Optimierte parallele Ausführung

Die SVM und ihre Sealevel-Laufzeit ermöglichen bekanntermaßen die parallele Transaktionsausführung. Transaktionen, die keinen überlappenden Status berühren, können parallel statt sequentiell ausgeführt werden.

Dadurch kann die SVM direkt mit der Hardware skaliert werden, da Prozessoren weiterhin mehr Kerne zu geringeren Kosten hinzufügen. Single-Threaded-Laufzeiten (wie das heutige EVM) profitieren grundsätzlich nicht von der Reduzierung der Kosten pro Kern. Seit über einem Jahrzehnt nehmen die Leistungssteigerungen durch Single-Threaded kontinuierlich ab. Fast alle Verbesserungen ergeben sich weiterhin aus der Erhöhung der Anzahl der Kerne. Daher ist es wichtig, diesen Trend durch Parallelisierung der Arbeitslasten zu nutzen:

Es gibt einige sehr frühe, unbewiesene Versuche, die EVM zu parallelisieren, aber das Hinzufügen dieser unter Beibehaltung der Kompatibilität bringt grundlegende Kompromisse mit sich, einschließlich suboptimaler Leistung, ohne andere Engpässe (z. B. Zustandswachstum) zu beheben. Verträge, die Zustandsabhängigkeiten im Voraus deklarieren (wie in der SVM), ermöglichen eine optimale Parallelisierung.

Lokale Gebührenmärkte

Die meisten Gebührenmärkte sind heutzutage global, was bedeutet, dass eine heiße Anwendung die Gebühren für alle Benutzer der Kette erhöht. Ein NFT-Mint sollte die Kette nicht für alles andere unbrauchbar machen. Solanas großartige Arbeit zu lokalen Gebührenmärkten löst diesen app-staatenübergreifenden Streit. In seiner aktuellen Implementierung priorisiert der Scheduler Transaktionen ohne Konflikte, sodass konfliktfreie Transaktionen mit geringeren Gebühren durchgeführt werden können. Längerfristig werden lokale Gebührenmärkte auf Protokollebene implementiert. Dadurch wird sichergestellt, dass sich Gebührenspitzen für eine einzelne App nicht auf den Rest der Kette auswirken.

Dank der einzigartig parallelisierten Laufzeit von Solana sind lokale Gebührenmärkte möglich. Der Versuch, lokale Gebührenmärkte für staatliche Hotspots im EVM mithilfe von Heuristiken zu implementieren (dh ohne den staatlichen Zugriff im Voraus zu deklarieren), würde Ineffizienzen und wahrscheinliche Angriffsvektoren mit sich bringen.

Es gibt auch erste Forschungsarbeiten , die es Anwendungen ermöglichen würden, den ihnen zugeschriebenen lokalen Wert leicht zu verinnerlichen, was heute im Allgemeinen ein kreativeres Design auf App-Ebene erfordert.

Staatliches Wachstumsmanagement

Bevor die EVM überhaupt auf die sequentielle Ausführung als Engpass stößt, ist das Zustandswachstum ihr weitaus dringlicherer Engpass.

Da es keinen Merkle-Baum für den Bundesstaat gibt, entsteht bei Solana nicht der Aufwand für die Aktualisierung eines Merkle-Baums für jede Statusaktualisierung. Stattdessen wird nach jeder Epoche (~2,5 Tage) der gesamte Zustand merklisiert. Dies ist viel günstiger als die Merklisierung in Echtzeit (wie im EVM).

Noch wichtiger ist, dass die EVM über einen dynamischen Kontozugriff verfügt (dh Transaktionen können bei Bedarf jeden Status berühren). Diese dynamische Statussuche bedeutet, dass dieser Status vor der Ausführung nicht in den Speicher geladen werden kann. In der SVM gibt jede Transaktion den gesamten Status an, der für die Ausführung erforderlich ist.

Daher hat die Statusgröße keinen Einfluss auf die SVM-Ausführung. Unter der Annahme, dass Validatoren ihre Speicherfestplatten alle zwei Jahre aktualisieren, könnte das Netzwerk die Snapshot-Größe sicher alle zwei Jahre verdoppeln, ohne auf größere Probleme zu stoßen.

Darüber hinaus verbessern Teams wie Helius aktiv die Zugänglichkeit historischer Daten und reduzieren die Zustandsgröße durch Komprimierung.

EVM-Kompatibilität

Neon EVM ist ein EVM, das als Smart Contract fungiert und in jeder SVM-Kette bereitgestellt werden kann. Dies bringt volle EVM-Kompatibilität mit Eclipse Mainnet (einschließlich EVM-Bytecode-Unterstützung und dem Ethereum JSON-RPC) mit höherem Durchsatz als Single-Threaded-EVMs. Da jede Neon-EVM-Instanz über einen eigenen lokalen Gebührenmarkt verfügt, können Apps einfach ihren eigenen Vertrag bereitstellen, um die Vorteile einer App-Kette zu nutzen, ohne UX, Sicherheit oder Liquidität zu fragmentieren.

Unabhängig davon ermöglicht der Solang- Compiler die Kompilierung von Solidity-Smart-Contracts-Code in SVM-Bytecode.

MetaMask-Snaps

Das Onboarding von EVM-Benutzern in Nicht-EVM-Ketten war in der Vergangenheit eine große Hürde, aber die kürzlich vorgestellten Metamask Snaps sollen diese Hürde überwinden. EVM-Benutzer können MetaMask weiterhin verwenden, ohne die Wallet wechseln zu müssen. Dank der Open-Source-Beiträge von Driftzum Aufbau einer großartigen MetaMask Snap-Implementierung ist die UX mit der Interaktion mit jeder EVM-Kette vergleichbar. Eclipse-Mainnet-Benutzer können nativ in MetaMask mit Apps interagieren oder eine Solana-native Wallet wie Salmon verwenden.

Hier ist ein kleiner Vorgeschmack auf die UX von Drift:

Feuertänzer

Firedancer ist der mit Spannung erwartete Solana-Client, der von Jump entwickelt wird, um den Durchsatz, die Widerstandsfähigkeit und die Effizienz des Netzwerks drastisch zu steigern. Beim Start werden wir uns so nah wie möglich an den Solana-Kernclient halten, aber wir planen, Firedancer zu übernehmen, sobald der Code live und stabil ist.

Sicherheit

Die Laufzeit von Solana verfügt über eine stark reduzierte Angriffsfläche, was die berüchtigten Wiedereintritts-Exploits verhindert, die wir viel zu oft gesehen haben. Konkret erlaubt die Solana-Laufzeitprogrammen nur die Selbstrekursion von Programmen, statt willkürliche reentrante programmübergreifende Aufrufe zuzulassen. Darüber hinaus führt die Trennung von Status und Code zu zustandslosem Code, der sich in der Regel einfacher und effektiver testen lässt.

Einfachere Prüfung

Die SVM ist registerbasiert und verfügt im Vergleich zur EVM über einen viel kleineren Befehlssatz, wodurch sich die SVM-Ausführung in ZK einfacher nachweisen lässt. Bei optimistischen Rollups ermöglicht das registerbasierte Design ein einfacheres Checkpointing.

Abwicklung: Sicherheit und Liquidität von Ethereum

Wie bei den heutigen großen Rollups wird sich das Eclipse Mainnet auf Ethereum niederlassen. Konkret bedeutet dies, dass unsere Validierungsbrücke auf Ethereum direkt in Eclipse verankert wird. Eclipse-Knoten greifen auf diese Brücke zurück, um die „kanonische Kette“ zu bestimmen. Die Bridge erzwingt die korrekte Reihenfolge für Eclipse.

Dadurch können unsere Nutzer bestimmte Sicherheitseigenschaften von Ethereum erhalten. Die Bridge validiert alle Eclipse-Transaktionen und verhindert so die Übermittlung ungültiger Zustände. Darüber hinaus wird es in bestimmten Fehlerfällen eine eventuelle Liveness und Zensurresistenz erzwingen. Selbst wenn der Sequenzer ausfallen oder auf L2 zensieren würde, könnten Benutzer die Einbeziehung ihrer Transaktionen über die Brücke erzwingen.

Aufgrund dieser Sicherheitseigenschaften werden Validium und Optimium oft als „Ethereum L2s“ bezeichnet. L2BEAT definiert einen L2 als „eine Kette, die ihre Sicherheit ganz oder teilweise von Layer-1-Ethereum ableitet, sodass Benutzer sich für die Sicherheit ihrer Gelder nicht auf die Ehrlichkeit von L2-Validatoren verlassen müssen.“

Die Ethereum-Vereinbarung erkennt die Bedeutung an, die native Vermögenswerte von Ethereum wahrscheinlich in der DeFi- und NFT-Wirtschaft von Eclipse Mainnet spielen werden. ETH ist das beste dezentrale Geld, das die meisten Benutzer eindeutig bevorzugen, daher werden wir ETH auch als unseren Gas-Token verwenden. Längerfristig wird die Gebührenabstraktion es Benutzern ermöglichen, mit jedem beliebigen Token ihrer Wahl (z. B. USDC) zu bezahlen. Derzeit ist nicht geplant, dass Eclipse Mainnet über einen eigenen Token verfügt.

Datenverfügbarkeit: Bandbreite und Überprüfbarkeit von Celestia

Eclipse Mainnet wird Celestia für die Datenverfügbarkeit nutzen (auch bekannt als: Datenveröffentlichung oder Datenveröffentlichung). Celestia ist ein langjähriger Ökosystempartner von Eclipse.

Der angestrebte Durchsatz und die Gebühren des Eclipse Mainnet werden von der aktuellen Bandbreite von Ethereum leider nicht unterstützt. Dies wird auch nach EIP-4844 (aka „Proto-danksharding“), das durchschnittlich ~0,375 MB Blobspace pro Block bereitstellt (mit einem Limit von ~0,75 MB pro Block).

  1. Für ERC-20-Übertragungen mit Basiskomprimierung (~154 Bytes pro Transaktion) entspricht dies über alle Rollups zusammengenommen etwa 213 TPS.
  2. Bei Swaps mit Komprimierung (ca. 400 Byte pro Transaktion) entspricht dies ca. 82 TPS über alle Rollups hinweg zusammen.

Im Vergleich dazu wird Celestia später in diesem Jahr mit 2-MB-Blöcken starten. Es wird erwartet, dass Blobspace kurz nach dem Start auf 8 MB ansteigt, sobald genügend Data Availability Sampling (DAS) -Lichtknoten online sind und sich das Netzwerk als stabil erweist. DAS-Lichtknoten erfüllen zwei wichtige Funktionen:

  1. Ermöglichen Sie Benutzern, selbst zu überprüfen, ob Eclipse-Blockdaten verfügbar gemacht wurden
  2. Tragen Sie zur sicheren Skalierung des gesamten Netzwerks bei, da DA-Schichten ihren Durchsatz sicher erhöhen können, wenn mehr DAS-Light-Knoten online gehen

Celestia wird voraussichtlich der erste DA-Layer sein, der DAS in Produktion bringt. Dies steht im Gegensatz zu herkömmlichen Data Availability Committees (DACs), die die Ehrlichkeitsannahmen der Komitees ohne Benutzerüberprüfung wieder einführen (ähnlich wie bei bestehenden monolithischen Blockchains).

Es gibt eine inhärente Sicherheitsannahme für Benutzer, die ihre Gelder vom Ethereum Mainnet auf jede Kette übertragen, die Off-Chain-DA verwendet. Insbesondere ist es Celestia-Validatoren technisch möglich, Transaktionsdaten zurückzuhalten, gegenüber der Ethereum-Brücke jedoch zu behaupten, dass die Daten verfügbar seien. In der Praxis bedeutet der Proof-of-Stake-Konsens von Celestia, dass die Zurückhaltung von Daten zu Celestia selbst drastisch reduziert werden kann, was dieses Risiko unserer Meinung nach unrealistisch macht.

Insgesamt machen Celestias DAS-Light-Node-Unterstützung vom ersten Tag an, kryptoökonomische Sicherheitseigenschaften und der hoch skalierbare DA-Durchsatz es heute zur klaren Wahl für Eclipse Mainnet.

Beachten Sie, dass einige die On-Chain-Ethereum-DA aus den oben beschriebenen Gründen als eine Voraussetzung ansehen, um hier ein echter „L2“ zu sein . Wir orientieren uns an der weiter oben genannten gebräuchlicheren L2-Terminologie und möchten die Sicherheitsaspekte klarstellen.

Wir beabsichtigen auch, die Fortschritte von Ethereum bei der DA-Skalierung nach EIP-4844 zu überwachen. Es kommen immer wieder spannende neue Forschungsergebnisse auf den Markt, die möglicherweise früher als frühere Ideen (die fortschrittlichere verteilte Hash-Tabellen verwenden) einen DA mit hohem Durchsatz bieten können. Wenn Ethereum zum Nutzen unserer Benutzer eine größere Skalierung für Eclipse bietet, würden wir die Möglichkeit einer Migration auf Ethereum DA prüfen.

Beweisen: RISC Zero ZK-Beweisnachweise für Betrug (ohne Zwischenstatus-Serialisierung!)

Unsere Prüfung wird ähnlich aussehen wie Anatolys SVM-Betrugsnachweise SIMD, was wiederum John Adlers Einsicht ähnelt, dass die staatliche Serialisierung teuer ist und dass es möglich ist, sie zu vermeiden.

Insbesondere möchten wir vermeiden, dass wieder ein Merkle-Baum in die SVM eingeführt wird. Wir haben schon früh damit experimentiert, einen Sparse-Merkle-Baum in die SVM einzufügen, aber die Aktualisierung des Merkle-Baums nach jeder Transaktion führt zu erheblichen Leistungseinbußen. Der Nachweis ohne Merkle-Baum schließt bestehende generalistische Rollup-Frameworks wie den OP-Stack als Grundlage für SVM-Rollups aus und erfordert außerdem eine kreativere fehlersichere Architektur.

Auf hohem Niveau erfordert ein Fehlernachweis:

  1. Eine Verpflichtung zu Eingaben für eine Transaktion,
  2. Die Transaktion selbst und
  3. Beweis, dass die erneute Ausführung der Transaktion zu einer anderen Ausgabe führt als der, die in der Kette angegeben wurde.

Die Eingabezusage erfolgt in der Regel durch die Bereitstellung der Merkle-Wurzel für den Statusbaum des Rollups. Unser Ausführender wird stattdessen eine Liste der Ein- und Ausgaben (einschließlich Konto-Hashes und des relevanten globalen Status) für jede Transaktion veröffentlichen, zusammen mit einem Index der Transaktion, die jede Eingabe erzeugt hat. Die Transaktionen werden in Celestia veröffentlicht, sodass jeder vollständige Knoten mitmachen kann, um Eingabekonten aus seinem eigenen Status abzurufen, die Ausgabekonten zu berechnen und zu bestätigen, dass die Verpflichtung zu Ethereum korrekt ist.

Es gibt zwei mögliche Arten schwerwiegender Fehler:

  1. Falsche Ausgaben – In diesem Fall liefert der Verifizierer einen ZK-Beweis in der Kette der korrekten Ausgaben. Wir verwenden RISC Zero, um ZK-Beweise der SVM-Ausführung zu erstellen und setzen damit unsere bisherige Arbeit zum Nachweis der BPF-Bytecode-Ausführung fort. Dadurch kann unser Abwicklungsvertrag die Korrektheit sicherstellen, ohne dass die Transaktionen selbst in der Kette ausgeführt werden müssen.
  2. Falsche Eingaben – In diesem Fall veröffentlicht der Verifizierer in der Kette einen Verweis auf die historischen Daten, aus dem hervorgeht, dass der Eingabestatus nicht den Angaben entspricht. Mithilfe der Quantengravitationsbrücke von Celestia stellt unser Vergleichsvertrag sicher, dass diese historischen Daten tatsächlich einen Betrug beweisen.

Warum Eclipse, warum Ethereum, warum jetzt

Wir stehen auf den Schultern von Riesen. Die heutigen Rollups haben den Forschungsstand für unsere gesamte Branche vorangebracht und Ethereum-Benutzern im Vergleich zu L1 günstigere Gebühren beschert.

Sie nutzen jedoch nicht alle Vorteile der neuesten Technologie aus, die für die Massentauglichkeit erforderlich ist. Frühe Rollups legten großen Wert auf EVM-Kompatibilität und/oder Optimierungen für eine effizientere ZK-Prüfung. In jüngerer Zeit haben wir jedoch unglaubliche Fortschritte gesehen, die die Notwendigkeit, diese Kompromisse einzugehen, die bei frühen Rollups beschlossen wurden, überflüssig machen und sie tatsächlich benachteiligen:

  1. Hochperformante parallelisierte VMs (z. B. SVM)
  2. DA-Skalierung mit DAS-Light-Node-Unterstützung (z. B. Celestia)
  3. Fortschritte in der Proof-Infrastruktur, um sie überall praktikabel zu machen (z. B. RISC Zero)
  4. Erhöhte Portabilität von Code (z. B. Neon und Solang) und Benutzern (z. B. MetaMask Snaps) über Ökosysteme hinweg

Eclipse hat den enormen Vorteil der Rückschau. Wir können aus den Einschränkungen lernen, mit denen andere Ketten konfrontiert waren, und dann die besten Stücke auswählen, um sie langfristig zu skalieren.

https://twitter.com/0xMert?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680271128537726976%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

https://twitter.com/colludingnode?refsrc=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680285353662468097%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

Wir hören oft von einer Zukunft mit einer Million App-spezifischen Rollups.

Anpassungen auf Konsensebene können für bestimmte Anwendungen (z. B. dYdX v4) unglaublich wertvoll sein, und wir freuen uns, Teams bei der Einführung anwendungsspezifischer Rollups zu unterstützen.

Allerdings sind diese Fälle selten. Aus diesem Grund sind die meisten neuen Rollups immer noch nur Vanilla-EVM-Forks. Die Probleme der Entwickler werden nicht durch die Fragmentierung von UX auf mehrere Ketten gelöst. Der Hauptanwendungsfall für eine Million Ketten scheint heute oft die Einführung einer Million weiterer Token zu sein. Für die überwiegende Mehrheit der Anwendungsfälle besteht heute einfach keine Nachfrage nach einer vollständigen Anpassung.

Selbst wenn die tatsächliche Nachfrage vorhanden wäre, wird die Infrastruktur, die zur Unterstützung vieler App-Ketten mit wettbewerbsfähiger UX erforderlich ist, noch Jahre entfernt sein (falls sie jemals den gleichen Wert erreicht). Die Superchain (OP Stack) von Optimism, die Hyperchains (ZK Stack) von zkSync, die Orbit-Ketten von Arbitrum usw. haben alle Visionen für viele Ketten mit gemeinsamer Infrastruktur. Dies soll einen reibungsloseren UX-Betrieb zwischen Ketten im selben Ökosystem (z. B. zwischen zwei Ketten innerhalb der Superchain) im Vergleich zu vollständig isolierten Ketten (z. B. zwischen Ethereum und Solana) ermöglichen.

Allerdings sind die aktuellen Pläne (sofern vorhanden) noch weit davon entfernt, jemals mit einem einzigen gemeinsamen Staat konkurrenzfähig zu sein. Darüber hinaus befassen sie sich nicht mit der Interoperabilität zwischen Ökosystemen (z. B. Superchain zu Hyperchain). Modular zu bauen sollte nicht bedeuten, Inseln zu bauen.

Für Benutzer ist es komplizierter, Konten über viele Ketten hinweg zu verwalten. Es ist noch schlimmer, UX ständig zu überbrücken und sich Gedanken darüber zu machen, welchen Gas-Token Sie benötigen. Es ist komplizierter und teurer, für den Betrieb und die Wartung so vieler Ketten auf Infrastrukturanbieter angewiesen zu sein.

Wir haben die Einfachheit von Solanas Vision immer geschätzt. Eine hochoptimierte gemeinsame Zustandsmaschine mit der Skalierung, die die meisten wertvollen Anwendungsfälle unterstützt. Dies wird oft als unvereinbar mit einer Rollup-zentrierten Roadmap angesehen, aber das ist einfach nicht der Fall. Wir wollen das Beste aus beiden Welten vereinen.

Dieses Missverständnis entsteht aufgrund der Tatsache, dass die heutigen Rollups die Vanilla-Single-Threaded-EVM weitgehend unverändert ausführen, um frühe Netzwerkeffekte zu nutzen. Daher sehen wir häufig „dedizierten Blockraum“ als Grund für die Bereitstellung eines App-spezifischen Rollups. Diese verrückten NFT-Mints sollten nicht die Preise für alle anderen Apps in Ihrer Kette in die Höhe treiben, aber die Antwort ist nicht, eine eigene Kette zu gründen. Das ist, als würde man mit einem Vorschlaghammer eine Erdnuss knacken. Sie gehen schmerzhafte und unnötige Kompromisse ein (Komplexität, Kosten, schlechtere UX, fragmentierte Liquidität usw.). Die optimale Lösung ist unglaublich klar: Verwenden Sie einfach eine parallelisierte VM mit lokalen Gebührenmärkten für staatliche Hotspots. Genau das bringt die SVM.

Ethereum ist das intellektuelle, soziale und wirtschaftliche Zentrum der Kryptowährung. Seine Achillesferse ist gewachsen. Die DA-Skalierung ist noch in Arbeit und die bestehenden L2-Ausführungsumgebungen können nicht mit neueren Innovationen wie der SVM konkurrieren. Wir befürchten, dass das Ethereum-Ökosystem in seiner jetzigen Form von einem starken Anstieg der Aktivität auf dem falschen Fuß erwischt würde. Single-Threaded-EVMs und eingeschränkte DA würden schnell zu einem Wiederaufleben hoher Gebühren führen, außer diesmal bei Rollups.

Wir glauben, dass Eclipse Mainnet die offensichtliche Lösung ist: Es vereint die Leistung von Solana mit der Sicherheit, Überprüfbarkeit und den Netzwerkeffekten der Rollup-zentrierten Roadmap.

Abschiedsgedanken

Das Schöne an Ethereum ist, dass es Innovationen frisst. Die Rollup-zentrierte Roadmap ist der Inbegriff dafür und delegiert Umsetzung und Innovation an den freien Markt. L2s verfügen über die unglaubliche Fähigkeit, die Netzwerkeffekte und Abwicklungsgarantien von Ethereum zu nutzen und gleichzeitig mit den besten neuen Ausführungsumgebungen zu experimentieren. Eclipse Mainnet ist die natürliche Erfüllung dieser Vision.

Wenn eines Tages eine leistungsfähigere Ausführungsschicht hinzukommt, werden wir uns riesig freuen, sie als wettbewerbsfähiges Ethereum L2 einzusetzen. Bis dahin bleibt die SVM der Standard.

Um mitzumachen, wenden Sie sich anhttp://mailto:team@eclipse.builders/team@eclipse.builders, um Testnet-Anweisungen zu erhalten.

Haftungsausschluss:

  1. Dieser Artikel wurde von [Mirror] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Eclipse]. Wenn Sie Einwände gegen diesen Nachdruck haben, 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.
Jetzt anfangen
Registrieren Sie sich und erhalten Sie einen
100
-Euro-Gutschein!