Die öffentliche Blockchain Gravity veröffentlicht Litepaper, das auf leistungsstarker EVM basiert und ein neues Benutzererlebnis bietet.

Ursprung des Textes: Gravity

Einleitung

Seit dem Start des Gravity Alpha Mainnets im August 2024 hat das Netzwerk über 275 Millionen Transaktionen verarbeitet, mit einem täglichen Transaktionsvolumen von bis zu 2,6 Millionen und erfolgreich 30 Millionen G Transaktionskosten erreicht. Mit der Veröffentlichung des Litepapers sind wir optimistisch über die zukünftige Entwicklung dieser leistungsstarken EVM-Chain. Dieser Artikel wird eine eingehende Analyse des Litepapers bieten und zeigen, wie Gravity eine hervorragende hochleistungsfähige Layer-1-Blockchain-Architektur für reale Anwendungen aufbauen wird.

Gravity ist eine leistungsstarke, EVM-kompatible Layer-1-Blockchain, die von Galxe entwickelt wurde. Die Entwicklung von Gravity ist aus den Bedürfnissen von Galxe entstanden. Die Galxe-Plattform ist die größte On-Chain-Distributionsplattform der Welt, die ein großes Mehrketten-Ökosystem verbindet und mehr als 25 Millionen Benutzer anzieht. Während dieses kontinuierlichen Entwicklungsprozesses hat sich Galxe zu einer dezentralen Superanwendung entwickelt, die innovative Werkzeuge wie Quest, Passport, Score, Compass und Alva integriert und gleichzeitig Dienstleistungen wie Loyalitätspunkte, Event-NFTs, Token-Belohnungen, zk-Identitätsnachweise und Cross-Chain-Smart-Savings anbietet. Im Rahmen dieser kontinuierlichen Entwicklung wurde das hohe Transaktionsvolumen von Galxe zu einem wichtigen Treiber für den Aufbau von Gravity - das Loyalitätspunktesystem unterstützt 51,2 Transaktionen pro Sekunde, während Token-Belohnungsaktivitäten 32,1 Transaktionen pro Sekunde unterstützen. Dies hat uns dazu veranlasst, beim Dezentralisieren des Galxe-Backends auf EVM-Blockchains umzusteigen und gleichzeitig das beste Benutzererlebnis zu gewährleisten.

Mit der vollständigen On-Chain-Entwicklung von Galxe ist ein weiteres Wachstum des Transaktionsvolumens zu erwarten. Der Durchsatzbedarf wird voraussichtlich 50 Millionen gas pro Sekunde erreichen, während die Erfüllung breiterer ökologischer Anforderungen (wie Cross-Chain-Abrechnungen, Loyalitätspunkthandel und NFT-Marktplatz) möglicherweise eine Verarbeitungsleistung von 500 Millionen gas pro Sekunde erfordert. Daher ist es das Ziel von Gravity, einen Durchsatz von 1 Gigagas pro Sekunde zu unterstützen, um den Skalierungsanforderungen ressourcenintensiver Anwendungen gerecht zu werden.

Von den bestehenden Lösungen setzen viele Plattformen auf Ethereum zur Skalierung, aber die Herausforderung von L2-Rollups führt unvermeidlich zu Verzögerungen bei den Transaktionen, was für Anwendungen wie Galxe, die sofortige Transaktionsbestätigungen benötigen, nicht freundlich ist. Obwohl einige DApps versuchen, Verzögerungen durch Vertrauensmodelle oder externe Überwachung zu kompensieren, bringen diese Methoden zusätzliche Komplexität und Risiken mit sich, die für zentrale Anwendungsszenarien klar nicht ideal sind.

In diesem Kontext entstand Gravity. Gravity basiert auf einer parallelen EVM und verkleinert durch die Entwicklung von Grevm, dem derzeit schnellsten Open-Source-parallelen EVM-Ausführungssystem, die Leistungsunterschiede zwischen L2 und L1. Darüber hinaus modularisiert Gravity die Architektur von Aptos und integriert bewährte Komponenten wie Quorum Store und AptosBFT-Konsensengine. Durch die Nutzung der ausgereiften Architektur von Aptos umgeht Gravity die Komplexität und potenziellen Risiken, die mit einer Neuentwicklung verbunden sind. Letztendlich hat Gravity nicht nur eine leistungsstarke L1-Blockchain geschaffen, die ein vollständiges Ketten-Erlebnis bietet, sondern auch das erste Pipeline-Blockchain-SDK eingeführt, das den Interaktionsprozess für Entwickler und Benutzer erheblich vereinfacht.

Gravity bietet beispiellose Skalierbarkeit, Dezentralisierungsfähigkeiten und nahezu sofortige Transaktionsgeschwindigkeiten. Seine Technologie kombiniert die Vorteile von L1 und L2 und erreicht 10.000 Transaktionen pro Sekunde mit Untersekunden-Endgültigkeit. Durch die Integration von Restaking-Protokollen wie EigenLayer und Babylon stellt Gravity nicht nur in der Startphase eine starke Sicherheit sicher, sondern verringert auch langfristig die systemischen Risiken, die mit der Abhängigkeit von einzelnen Vermögenswerten verbunden sind.

In Zukunft wird Gravity gemäß der folgenden Roadmap vorankommen:

· Einführung von Devnet Phase 1, um die Echtzeitleistung zu testen;

· Start des Longevity Testnet, um die langfristige Stabilität des Netzwerks zu überprüfen;

· Übergang vom Gravity Alpha Mainnet zu einem vollständig operativen Gravity Mainnet, um die Grundlage für die großflächige Anwendung dezentraler Technologien zu schaffen.

Hier ist die vollständige Zusammenstellung des Gravity Litepapers.

Zusammenfassung

Gravity ist eine leistungsstarke, EVM-kompatible Layer-1-Blockchain, die von Galxe entwickelt wurde und für groß angelegte Anwendungen und Mehrketten-Ökosysteme konzipiert ist. Zu den besonderen Merkmalen gehören ein Durchsatz von 1 Gigagas pro Sekunde, Untersekunden-Transaktionsbestätigungszeiten und ein PoS-Konsensmechanismus, der auf Restaking-Protokollen basiert. Das Design von Gravity stützt sich auf zwei Hauptkomponenten, die als Open Source verfügbar sind: (1) Gravity SDK, ein pipelinebasierter AptosBFT PoS-Konsensengine; (2) Gravity reth, eine Ausführungsschicht, die mit dem parallelen EVM Grevm (Gravity EVM) betrieben wird. Diese Werkzeuge bieten die Möglichkeit, alternative Layer-1- und effiziente Layer-2-Anwendungen für Web3 zu erstellen, insbesondere auf EVM-Chain. Dieser Artikel untersucht eingehend das Engineering-Design und die technischen Innovationen von Gravity und zeigt, wie durch die Pipeline-Architektur, fortschrittliche Konsensalgorithmen, parallele Ausführungstechnologien und optimierte Speichermechanismen (durch die Verbesserung von reth und die Verbesserung des Aptos-Konsensengine) hohe Leistungsanforderungen erfüllt werden können.

Einleitung

Die Entwicklung von Gravity ist aus den Herausforderungen entstanden, denen Galxe im Betrieb gegenüberstand. Galxe ist eine führende Web3-Anwendung, die den Benutzern Loyalitätspunkte, Event-NFTs, Token-Belohnungen, Zero-Knowledge-Identifikationen und Cross-Chain-Smart-Savings bietet. Mit dem rasanten Wachstum von Galxe verarbeitet das Loyalitätspunktesystem durchschnittlich 51,2 Transaktionen pro Sekunde, während Token-Belohnungsaktivitäten durchschnittlich 32,1 Transaktionen pro Sekunde unterstützen. Im Zuge der schrittweisen Dezentralisierung von Galxe wurde es zu einer Herausforderung, diese Anwendungsfälle auf EVM-Blockchains zu migrieren und gleichzeitig ein reibungsloses Benutzererlebnis sicherzustellen. Daher wurde die Entwicklung einer leistungsstarken EVM-Blockchain, die (1) hohen Transaktionsdurchsatz und (2) nahezu sofortige Transaktionsbestätigungen bieten kann, entscheidend.

In diesem Kontext ist die Wahl bestehender Layer-2-Lösungen oder die Entwicklung neuer Layer-1-Blockchains ein entscheidender Entscheidungspunkt. Layer-1 erreicht die Endgültigkeit durch den Konsensalgorithmus, während Layer-2 dieses Problem durch Rollup-Protokolle löst. Es gibt Kompromisse: Layer-1 opfert in der Regel einen Teil des Durchsatzes aufgrund von Beschränkungen des Konsensalgorithmus, kann jedoch schnellere Transaktionsbestätigungen erreichen. Beispielsweise kann der auf AptosBFT basierende Konsensalgorithmus Transaktionen in Untersekunden bestätigen, während optimistische Rollups aufgrund von Challenge-Fristen von bis zu sieben Tagen Verzögerungen haben. Obwohl Zero-Knowledge-Beweise diesen Prozess beschleunigen können, sind die endgültigen Bestätigungen noch immer Stunden später erforderlich. Angesichts des Bedarfs von Gravity an Untersekunden-Endgültigkeit (insbesondere für das gesamte Kettenintentprotokoll) haben wir uns entschieden, Layer-1 zu entwickeln.

Obwohl Layer-2 in der Kommunikation mit Ethereum einen nativen Vorteil hat, kann eine Layer-1 wie Gravity durch das Gravity-Intent-Protokoll und Cross-Chain-Brücken eine tiefe Interoperabilität mit Ethereum und anderen Blockchains erreichen. Dieses Design ermöglicht nicht nur eine nahtlose Zusammenarbeit mit Ethereum, sondern verbessert auch die Konnektivität des gesamten Web3-Ökosystems.

Darüber hinaus hat das Restaking-Protokoll (restaking) die Schwierigkeit des Aufbaus einer PoS Layer-1-Blockchain erheblich verringert. Gravity integriert durch Protokolle wie EigenLayer und Babylon die gestakten Vermögenswerte von Ethereum und Bitcoin sowie deren umfangreiche Validator-Netzwerke. Dies gewährleistet die wirtschaftliche Absicherung des PoS-Konsenses und bringt die Dezentralisierung und Sicherheit von Gravity auf ein Niveau, das mit Ethereum vergleichbar ist.

Zusammenfassend lässt sich sagen, dass Gravity als hochleistungsfähige, EVM-kompatible Layer-1-Blockchain entwickelt wurde, um den Skalierungs- und Leistungsanforderungen moderner Web3-Anwendungen gerecht zu werden. Obwohl die ursprüngliche Absicht darin bestand, Galxe zu bedienen, bietet das flexible Framework von Gravity SDK und Grevm (Gravity EVM) die Möglichkeit, jede Layer-1- und effiziente Layer-2-Anwendung zu erstellen, ähnlich wie Tendermint/Cosmos SDK.

Wir benötigen 1 gigagas/s Durchsatz

Für Blockchains ist der Durchsatz das kritischste Leistungsmerkmal, das normalerweise in Transaktionen pro Sekunde (TPS) oder Gasverbrauch pro Sekunde (gas/s) gemessen wird. Zum Beispiel verlangt das Loyalitätspunktesystem von Galxe mindestens 4 Millionen gas/s, um stabil zu laufen. Diese Zahl wird aus dem durchschnittlichen Gasverbrauch von 80.000 gas pro Loyalitätspunktetransaktion und der Fähigkeit abgeleitet, etwa 51,2 Transaktionen pro Sekunde zu verarbeiten.

Diese Vorhersage wurde durch praktische Daten des Gravity Alpha Mainnets unterstützt. Als unser Test-Layer-2-Netzwerk zeigt der Loyalitätspunktetransfer des Gravity Alpha Mainnets, dass sein Durchsatz stabil bei 4 Millionen gas/s erreicht werden kann, was die Richtigkeit der oben genannten Schätzung bestätigt.

Obwohl die hohen Kosten für On-Chain-Operationen zu einem leichten Rückgang der Nachfrage führen können, zeigt der Expansionstrend von Galxe, dass die Nachfrage zu Spitzenzeiten auf das Zwei- bis Dreifache des aktuellen Niveaus steigen könnte. Darüber hinaus, mit dem Hinzufügen anderer Anwendungsfälle wie NFT, Token-Belohnungen und zukünftige Zero-Knowledge-Proof-unterstützte On-Chain-Aufgaben, wird erwartet, dass der Durchsatzbedarf 50 Millionen gas/s erreichen wird, wenn Galxe vollständig on-chain wird. Angenommen, die Gasnutzung der Anwendungen auf der Gravity-Kette folgt einer Pareto-Verteilung (ähnlich wie Uniswap, das kontinuierlich 10 % des Gasverbrauchs von Ethereum beansprucht), sollte sie idealerweise einen Durchsatz von 500 Millionen gas/s unterstützen, um breitere ökologische Anforderungen wie Cross-Chain-Abrechnungen, Loyalitätspunkthandel und NFT-Marktplätze zu erfüllen. Daher muss die Blockchain einen Durchsatz von 1 Gigagas pro Sekunde bieten, um sicherzustellen, dass sie den Anforderungen ressourcenintensiver Anwendungen gerecht werden kann.

Um einen so hohen Durchsatz zu erreichen, ist die Einführung einer parallelen EVM von entscheidender Bedeutung. Wir haben Grevm entwickelt, das derzeit schnellste Open-Source-parallele EVM-Ausführungssystem, dessen spezifische Leistung in den folgenden Kapiteln beschrieben wird.

Untersekunden-Bestätigungszeiten

Neben der Durchsatzrate ist die Bestätigungszeit der Transaktionen für das Benutzererlebnis von entscheidender Bedeutung. Moderne Benutzer sind an nahezu sofortige Reaktionen wie bei Web2 gewöhnt, was für Blockchains nach wie vor eine Herausforderung darstellt. Ein Beispiel ist Galxe, das ähnliche Anforderungen an niedrige Latenz wie bei vollständig on-chain-Spielen hat. Derzeit variiert die Bestätigungszeit der Transaktionen bei den meisten EVM-Blockchains von einigen Sekunden bis mehreren Tagen, was bei weitem nicht ausreicht, um diese Anforderungen zu erfüllen. Wir haben den AptosBFT-Konsensalgorithmus gewählt, um Untersekunden-Bestätigungszeiten zu erreichen.

Obwohl L2-Rollups theoretisch den Durchsatz erhöhen können, führt die Herausforderung dieser Rollups zu Verzögerungen bei Transaktionen, was für Anwendungen, die sofortige Transaktionsbestätigungen erfordern (wie Galxe), sehr nachteilig ist. Obwohl einige DApps versuchen, dies durch Vertrauensmodelle oder externe Überwachung zu optimieren, bringt dies zusätzliche Komplexität und Risiken mit sich, die für kritische Anwendungen nicht ideal sind. Das Gravity SDK verkürzt durch das Design einer fünfstufigen Pipeline die Leistungsunterschiede zwischen Konsens und Ausführung und verringert die Lücke zwischen L2 und L1 (genaue Designs siehe unten).

PoS-Sicherheit basierend auf Restaking

Gravity SDK bietet eine sichere Möglichkeit zur Skalierung von Ethereum, die sich nicht auf L2-Rollups beschränkt, sondern eine durch Restaking geschützte Layer-1-Architektur wählt, um Leistung, Interoperabilität und Sicherheit in Einklang zu bringen. Die Kernmodule integrieren Restaking-Protokolle wie EigenLayer und Babylon und bieten wirtschaftliche Vertrauensunterstützung, um einen robusten Proof-of-Stake-Konsens zu gewährleisten.

Mit den 45 Milliarden Dollar an gestakten Vermögenswerten und 850.000 Validatoren von Ethereum sowie den 600 Milliarden Dollar an Vermögenswerten, die durch Babylon von Bitcoin integriert werden, kann Gravity von Anfang an eine solide Sicherheitsbasis aufbauen und die typischen Startprobleme und Sicherheitsrisiken neuer Blockchains vermeiden, während es langfristig das systemische Risiko reduziert, das mit der Abhängigkeit von einzelnen Vermögenswerten verbunden ist.

Gravity Chain Architektur

Gravity Chain besteht aus zwei Hauptkomponenten: Gravity SDK und Gravity reth. Gravity SDK ist ein verbessertes Blockchain-Framework, das von der Aptos-Chain abgeleitet ist, wobei Aptos die derzeit fortschrittlichste PoS-Blockchain ist, die auf der HotStuff-Konsensfamilie basiert und deren Pipeline-Architektur den Durchsatz und die Ressourceneffizienz erheblich steigert. Gravity reth ist die auf reth basierende Ausführungsschicht, die im Block Stream Reactor (BSR)-Modus betrieben wird, um die von der Konsensschicht vorgeschlagenen Blöcke zu empfangen. Durch die Optimierung von reth ermöglicht Gravity reth parallele Ausführung, asynchrone Batch-Statusverpflichtungsberechnungen und eine erhöhte Speichereffizienz. Diese beiden Komponenten sind über die Gravity Consensus Engine Interface (GCEI) und den reth-Adapter eng miteinander verbunden und werden vom Pipeline-Controller dynamisch verwaltet, um den Fortschritt jeder Phase zu steuern.

Dieses Design trennt die Blockausführung vom Blockkonsens, sodass die Ausführungsschicht als Verbraucher des Blockvorschlags fungiert. Unsere Optimierungen von reth machen es perfekt an den von Block Stream Reactor (BSR) verwalteten Pipeline-Blockvorschlagsprozess anpassbar.

Der Transaktionsprozess von Gravity Chain ist wie folgt:

1. Transaktionen werden über die Gravity reth JSON RPC-Schnittstelle eingereicht, die vollständig kompatibel mit Ethereum ist.

2. Danach gelangt die Transaktion in den Speicherpool des Gravity SDK und wird im Netzwerk verbreitet, wobei die Validatoren die Transaktionen in Chargen verarbeiten und Quorum Store (QS)-Zertifikate generieren.

3. Bei jedem Zyklus schlägt der Anführer einen Blockvorschlag vor, der Blockmetadaten und aus dem Speicherpool sowie QS ausgewählte sortierte Transaktionen enthält.

4. Vorschläge werden als geordnet gekennzeichnet und gelangen dann in die Ausführungsschicht.

5. Die Ausführungsschicht von Grevm verarbeitet Transaktionen parallel, generiert Ausführungsergebnisse und übergibt den neuen Status an das Statusmanagementmodul.

6. Das Statusmodul berechnet die Statuswurzel und übermittelt sie an den Konsensengine, um die Statuswurzelkonsens zu erreichen.

7. Nachdem die endgültige Bestätigung der Statuswurzel erfolgt ist, persistiert das Speichermodul die Statuswurzel und die Blockdaten.

Die folgenden Abschnitte werden jede Komponente ausführlich beschreiben.

Gravity SDK: Innovative Praktiken in der Open-Source-Pipeline-Blockchain

Gravity SDK ist ein modulares Open-Source-Blockchain-Framework, das auf der produktionsbereiten Aptos-Blockchain entwickelt wurde. Ziel ist es, die Architektur von Aptos zu modularisieren und bewährte Komponenten wie Quorum Store und AptosBFT-Konsensengine zu integrieren, um das erste Pipeline-Blockchain-SDK zu schaffen.

Die Gründe, warum Gravity SDK Aptos als Grundlage gewählt hat, sind:

· Hochmoderne technische Architektur: Aptos ist eine fortschrittliche PoS-Blockchain, die auf der HotStuff-Familie von Konsensmechanismen basiert.

· Höchste Leistungsfähigkeit: Aptos bietet einen Durchsatz von 160.000 Transaktionen pro Sekunde und eine endgültige Bestätigungszeit von weniger als 1 Sekunde.

· Praktische Zuverlässigkeit: Aptos hat sich in der Produktionsumgebung bewährt und zeigt außergewöhnliche Stabilität und Effizienz.

· Vermeidung von Doppelarbeit: Die Nutzung der ausgereiften Architektur von Aptos kann die Komplexität und potenziellen Risiken, die mit einer Neuentwicklung verbunden sind, umgehen, während andere Versuche, Aptos zu übertreffen, meist theoretisch und praktisch unzureichend sind.

· Synergie-Effekte: Mit der kontinuierlichen Entwicklung von Aptos kann das Gravity SDK nahtlos neue Funktionen wie die Zufallszahl-API integrieren und gleichzeitig Aptos durch modulare Architektur und innovative Sicherheitsmechanismen unterstützen.

Die auf dem Gravity SDK basierende Blockchain verbindet sich über die Gravity Consensus Engine Interface (GCEI) mit dem pipeline-basierten Konsensusengine. Obwohl GCEI mit verschiedenen Ausführungsschichten kompatibel ist, unterstützt das Gravity SDK derzeit hauptsächlich Gravity reth. Detaillierte Informationen über GCEI werden in den folgenden Abschnitten behandelt.

Gravity Consensus Engine Interface (GCEI)

Das GCEI (Gravity Consensus Execution Interface) Protokoll ist die Kommunikationsbrücke zwischen der Konsensschicht und der Ausführungsschicht. Es regelt die Interaktionen zwischen den beiden Schichten und stellt sicher, dass die Konsens- und Ausführungsabläufe durch den Pipeline-Controller synchronisiert bleiben.

Der Hauptunterschied zwischen herkömmlichen Blockchain-SDKs und Gravity SDK liegt in ihrem pipelinebasierten Konsensus-Engine. Die Ausführungsschicht muss als Block Stream Reactor implementiert werden, was bedeutet, dass sie in der Lage sein muss, den vorgeschlagenen Blockstream kontinuierlich zu konsumieren, und die Statusverpflichtung muss asynchron zur Transaktionsausführung berechnet werden. Darüber hinaus muss die Ausführungsschicht in der Lage sein, der Konsensschicht Drucksignale zu geben, um das Tempo des Blockvorschlags dynamisch anzupassen.

Darüber hinaus muss die Ausführungsschicht aufgrund der Pipeline-Eigenschaften des Gravity SDK in der Lage sein, nicht ausführbare Transaktionen in den vorgeschlagenen Blöcken zu verarbeiten, da der Speicherpool aufgrund des fehlenden Zugriffs auf den neuesten Weltstatus keine strenge Überprüfung der Gültigkeit von Transaktionen durchführen kann: Die Ausführung könnte noch nicht abgeschlossen sein. Gleichzeitig sollten die Ausführungsergebnisse die Erzeugung nachfolgender Blöcke nicht blockieren, da die Ausführungsschicht nach der Parallelisierung des Blockkonsenses mit der Statuskonsens eine Reaktion auf den Vorschlag von Blockströmen geworden ist, die die Ergebnisse der Ausführung in späteren Phasen zurückgeben kann.

Das GCEI-Protokoll definiert zwei Gruppen von APIs:

· Konsensschicht API: Diese APIs werden vom Gravity SDK implementiert, um auf die vom Konsensengine vorgeschlagenen Blöcke zu reagieren und Statusverpflichtungen einzureichen.

· Ausführungsschicht API: Diese APIs müssen von der Ausführungsschicht implementiert werden. Die Konsensmaschine wird diese APIs verwenden, um Transaktionen vor der Blockvorschlag zu validieren, den vorgeschlagenen Block zu streamen und die endgültige Statusverpflichtung an die Ausführungsschicht zu kommunizieren.

Aus der Perspektive des Lebenszyklus von Transaktionen definiert das GCEI-Protokoll Folgendes:

1. check_txn (Ausführungsschicht API)

· Eingabe: Erhält eine Transaktion (GTxn) als Eingabe.

· Ausgabe: Gibt die Adresse des Absenders der Transaktion, das nonce und die Gasgrenze zurück.

Verwendung: Diese Methode wird verwendet, damit der Konsensengine vor dem Vorschlag der Transaktion zu einem Block eine Anstrengungsvalidierung durchführt. Diese Methode kann mehrmals für dieselbe Transaktion aufgerufen werden, z.B. wenn die Transaktion in den Speicherpool eingeht, bevor sie zum Block vorgeschlagen wird, und wenn die Statusverpflichtung endgültig festgestellt wird.

2. submit_txn (Konsensschicht API)

Eingabe: Erhält eine Transaktion (GTxn) von der Ausführungsschicht.

Ausgabe: Gibt Result<() zurück, das angibt, ob die Transaktion erfolgreich zum Speicherpool hinzugefügt wurde.

Verwendung: Die Ausführungsschicht kann diese Methode verwenden, um Transaktionen in den Speicherpool einzureichen. Der Konsensengine wird dann diese Transaktion über das Netzwerk verbreiten und ein Quorum Store bilden, nachdem eine Gruppe von Transaktionen empfangen wurde.

3. recv_ordered_block (Ausführungsschicht API)

Eingabe: Erhält einen ordered_block (Typ BlockBatch), der die sortierten Transaktionen und Blockmetadaten enthält.

Ausgabe: Gibt Result<() zurück, das angibt, ob die Ausführungsschicht den Block erfolgreich empfangen und akzeptiert hat.

Verwendung: Sobald der Konsensengine einen Block vorgeschlagen hat, wird er zur Ausführungsschicht gesendet, um die Transaktionen auszuführen. Diese Methode ermöglicht der Ausführungsschicht, den vorgeschlagenen Block zu empfangen und zu verarbeiten.

4. update_state_commitment (Konsensschicht API)

Eingabe: Statusverpflichtung (StateCommitment) eines bestimmten Blocknummer.

Ausgabe: Gibt Result<() zurück, das angibt, ob die Statusverpflichtung erfolgreich vom lokalen Konsensengine akzeptiert wurde.

Verwendung: Nachdem die Ausführungsschicht die Statusverpflichtung berechnet hat, wird sie an die Konsensschicht gesendet, um die endgültige Bestätigung zu erreichen, d.h. um einen leichten Konsens von 2f+1 mit anderen Validatoren zu erreichen. Wenn die Konsensüberprüfung der Statusverpflichtung zu weit vom Fortschritt des vorgeschlagenen Blocks abweicht, wird der Pipeline-Controller das Tempo des Blockvorschlags anpassen.

5. commit_block_hash (Ausführungsschicht API)

Eingabe: Erhält einen Satz von block_ids-Vektoren, die die zu übermittelnden Blöcke darstellen.

Ausgabe: Gibt Result<() zurück, das den Erfolg der Operation anzeigt.

Verwendung: Wenn die Statusverpflichtung endgültig festgelegt ist, benachrichtigt die Konsensschicht die Ausführungsschicht, um den Blockhash im Blockchain-Speicher zu speichern.

Blockchain-Pipeline

Das Gravity SDK maximiert die Nutzung der Hardware-Ressourcen durch eine fünfstufige Pipeline-Architektur, um höhere Durchsatzraten und geringere Latenzen zu erreichen. In der Pipeline werden Aufgaben zwischen verschiedenen Blöcken überlappt ausgeführt, und der Pipeline-Manager verwendet ein Feedback-System, um einen stetigen Fortschritt der Blockchain sicherzustellen. Die ersten drei Stufen gehören zur Konsensschicht, während die letzten beiden Stufen zur Ausführungsschicht gehören.

Die einzelnen Phasen sind wie folgt erläutert:

· Phase 1: Transaktionsverbreitung: In dieser Phase wird die Transaktion effizient zwischen den Validatoren verbreitet, um sicherzustellen, dass die Transaktion während des Blockbaus rechtzeitig und zuverlässig enthalten ist. Das Design entkoppelt die Transaktionsverbreitung von den Konsensmechanismen und folgt den Prinzipien von Narwhal & Tusk und Aptos, wobei Validatoren kontinuierlich Transaktionsbatches teilen, um alle Netzwerkrressourcen parallel zu nutzen. Wenn ein Batch von Transaktionen 2f+1 gewichtete Signaturen erhält (was zu PoAv, d.h. Verfügbarkeitsnachweisen, führt), wird sichergestellt, dass dieser Batch von mindestens f+1 ehrlichen Validatoren gespeichert wird, sodass alle ehrlichen Validatoren diese Transaktionen zur Ausführung abrufen können.

· Phase 2: Sortierung der Blockmetadaten: In dieser Phase wird eine konsistente und allgemein anerkannte Reihenfolge von Transaktionen und Blockmetadaten im Netzwerk etabliert. Der Konsensmechanismus (AptosBFT) folgt den 2-Chain-Regeln, um Byzantine-fehlerresistente Blöcke bereitzustellen. Die Blöcke fließen dann in die Ausführungsphase ein und werden auf die parallele Verarbeitung vorbereitet.

· Phase 3 (BSR): Parallele Transaktionsausführung: Diese Phase gehört zur Ausführungsschicht, in der Transaktionen parallel ausgeführt werden. Die Ausführungsergebnisse werden an die Statusverpflichtungsphase übergeben.

· Phase 4: Statusverpflichtung: In dieser Phase werden die durch die Transaktionsausführung verursachten Statusänderungen abgeschlossen und die endgültige Blockbestätigung vorbereitet. Statusverpflichtung und Transaktionsausführung erfolgen asynchron, um sicherzustellen, dass die Ausführung des nächsten Blocks nicht durch die aktuelle Blockstatusverpflichtung behindert wird.

· Phase 5: Statuspersistierung: In dieser Phase werden die festgelegten Statusänderungen in den Blockchain-Speicher persistiert. Die endgültige Statuswurzel und die zugehörigen Daten werden im Gravity Store gespeichert, der eine hochoptimierte Speicher-Engine verwendet, die für schnellen Zugriff und Zuverlässigkeit ausgelegt ist. Gleichzeitig werden der Speicherpool und der Quorum Store benachrichtigt, um Transaktionen zu bereinigen, die in Zukunft nicht mehr enthalten werden können.

Staking- und Restaking-Module

Der Aufbau einer sicheren Proof-of-Stake (PoS) Layer-1-Blockchain ist eine komplexe Aufgabe, insbesondere wenn die Staking nur auf spezifischen Token auf der Kette basiert. Diese Methode könnte in den frühen Phasen mit unzureichender wirtschaftlicher Sicherheit konfrontiert werden, beispielsweise durch Wertschwankungen der Token oder eine begrenzte Teilnahme der Validatoren. Um dieses Problem zu lösen, bietet das Gravity SDK ein flexibles Staking- und Restaking-Modul, das darauf abzielt, die Sicherheit des Netzwerks durch lokale und externe Staking-Mechanismen zu erhöhen.

Eine der Schlüsselstrategien des Gravity SDK ist die Einführung von Restaking-Protokollen wie EigenLayer und Babylon. Diese Protokolle ermöglichen es Validatoren, Vermögenswerte anderer reifer Netzwerke wie Ethereum und Bitcoin erneut zu staken und somit die vorhandenen Sicherheitsgarantien zu nutzen. Durch die Erlaubnis für Validatoren, Vermögenswerte dieser Ketten zu staken, kann das Gravity SDK die wirtschaftliche Sicherheit des Netzwerks erhöhen, ohne vollständig auf lokale Token angewiesen zu sein. Diese Methode stärkt nicht nur die Robustheit der Kette, sondern fördert auch die Diversität des Validator-Ökosystems. Das Design des Staking-Moduls ist modular aufgebaut, wobei die Restaking-Komponenten eine hohe Flexibilität aufweisen, um sich leicht an neue Restaking-Protokolle anzupassen, während sich das Blockchain-Ökosystem weiterentwickelt.

Dieses Modul unterstützt nicht nur Restaking-Vermögenswerte, sondern auch das Staken von benutzerdefinierten ERC20-Token, die auf unterstützten Ketten wie Ethereum verfügbar sind. Validatoren können sich durch das Staking dieser zulässigen Token am Konsens beteiligen und zur Sicherheit des Netzwerks beitragen. Das Stimmrecht der Validatoren wird basierend auf ihrem gesamten Staking-Wert berechnet, einschließlich benutzerdefinierter Token und Vermögenswerte im Restaking-Protokoll. Diese Berechnung erfolgt gemäß der spezifischen Konfiguration der Kette, um sicherzustellen, dass jede Kette ihre Staking- und Restaking-Regeln flexibel an ihre Anforderungen anpassen kann.

Der Epoch-Manager im Konsensengine arbeitet direkt mit dem Staking-Modul zusammen, um das Gewicht der Validatoren für die nächste Runde zu berechnen. Er stellt durch den Erhalt von Staking-Werten von der Ausführungsschicht sicher, dass der Konsensprozess die neuesten Staking-Dynamiken genau widerspiegelt. In dieser Architektur müssen Cross-Chain-Vermögenswerte (z. B. gestakte Vermögenswerte von Ethereum) zuerst zur Ausführungsschicht überbrückt werden, bevor sie zur Berechnung des Gesamtstakings der Validatoren verwendet werden können. Die Implementierung des Bridge-Mechanismus liegt in der Verantwortung der Ausführungsschicht, um eine flexiblere Handhabung von Cross-Chain-Kommunikation zu ermöglichen. Mögliche Lösungen umfassen PoS-Brücken, Zero-Knowledge-Beweise des Kettenstatus und eingebettete, selbststartende Cross-Chain-Nachrichtenübertragung.

Mehr technische Details, API-Design und vollständige Erklärungen der Staking- und Restaking-Mechanismen werden in zukünftigen Dokumenten ausführlich behandelt.

Gravity Reth: Block Stream Reactor EVM-Ausführungsschicht

Die Integration der EVM-Ausführungsschicht in die Architektur des Gravity SDK bringt einzigartige Herausforderungen mit sich, insbesondere bei der optimalen Nutzung der Fähigkeiten des pipeline-basierten Konsensusengine. Um eine nahtlose Integration und volle Entfaltung des Potenzials dieser Architektur zu ermöglichen, müssen mehrere Schlüsseloptimierungen am Open-Source-Ethereum-Client reth vorgenommen werden. Diese Optimierungen verwandeln reth grundlegend in Gravity reth, eine für den pipeline-basierten Konsensusengine maßgeschneiderte optimierte EVM-Ausführungsschicht.

Traditionelle Blockchain-Architekturen verarbeiten Blöcke sequenziell und stellen sicher, dass jeder Block vollständig validiert und ausgeführt wird, bevor der nächste Block vorgeschlagen wird. Gravity SDK hingegen verwendet einen Pipeline-Konsensmechanismus, der die verschiedenen Phasen der Blockverarbeitung trennt, um die Leistung zu steigern. Dieser Paradigmenwechsel bringt jedoch Komplexität mit sich:

Unerwartete Transaktionen: In der Pipeline-Chain kann der Speicherpool aufgrund der möglicherweise noch nicht abgeschlossenen Ausführung des vorherigen Blocks nicht auf den neuesten Weltstatus zugreifen. Daher kann die Ausführung der Transaktionen, die im vorgeschlagenen Block enthalten sind, möglicherweise nicht durchgeführt werden, da ihre Gültigkeit ohne den neuesten Status nicht streng verifiziert werden kann.

Nicht blockierende Ausführungsergebnisse: Um eine Stilllegung der Pipeline zu vermeiden, sollten die Ausführungsergebnisse die Erzeugung nachfolgender Blöcke nicht blockieren. Die Ausführungsschicht muss in der Lage sein, vorgeschlagene Blöcke asynchron zu verarbeiten und die Ausführungsergebnisse in späteren Phasen zurückzugeben, ohne den Konsensprozess zu behindern. Für EVM bedeutet dies, dass wir den Blockhash neu definieren müssen, um die Abhängigkeit vom StatusRoot-Feld im Blockheader zu beseitigen.

Um diese Probleme zu lösen, haben wir vier Schlüsseloptimierungen eingeführt:

· Block Stream Reactor (BSR): BSR wurde entwickelt, um reth an den Pipeline-Blockvorschlagsprozess des Gravity SDK anzupassen. Es ermöglicht der Ausführungsschicht, den vorgeschlagenen Blockstream kontinuierlich zu konsumieren und als Reaktor für die asynchrone Verarbeitung von Blöcken zu fungieren. BSR schafft einen dynamischen Feedbackzyklus mit der Konsensmaschine, kombiniert mit geeigneten Drucksignalen. Diese Signale passen die Geschwindigkeit des Blockvorschlags und der Statusverpflichtung in Echtzeit an, basierend auf dem Durchsatz und der Verzögerung der Ausführungsschicht. Wenn es aufgrund komplexer Transaktionen oder Ressourcenbeschränkungen zu Verzögerungen in der Ausführungsschicht kommt, reduziert der Druckmechanismus die Vorschlagsrate von Blöcken, um die Stabilität des Systems sicherzustellen.

· Entkopplung der Statusverpflichtung von der Transaktionsausführung: Die zweite Optimierung betrifft die Trennung der Berechnung der Statusverpflichtung von der Transaktionsausführung. Durch die Entkopplung dieser Prozesse ermöglichen wir die asynchrone Berechnung der Statusverpflichtung, sodass die Ausführung nachfolgender Blöcke nicht auf den Abschluss der Statusverpflichtung des aktuellen Blocks warten muss. Wir haben den Blockhash neu definiert, um die Abhängigkeit von dem StatusRoot-Feld im Blockheader zu beseitigen, und sicherzustellen, dass die Berechnung der Statuswurzel die Erzeugung nachfolgender Blöcke nicht blockiert.

· Optimierung der Speicherschicht: In der Pipeline-Architektur ist die effiziente Speicherung und Persistierung von Mehrversionen von Statuswerten und Statusverpflichtungen entscheidend. Die dritte Optimierung konzentriert sich darauf, die Speicherschicht zu verbessern, um diese Anforderungen zu erfüllen, ohne Engpässe zu verursachen. Durch die Optimierung des Speichersystems stellen wir sicher, dass Statusdaten schnell geschrieben und hochgradig parallel abgerufen werden können. Dazu gehört der Aufbau einer Mehrversionsspeicher-Engine und die Unterstützung von asynchrone I/O von der Datenbank zur Speicher-API.

· Parallele EVM: Die letzte Optimierung betrifft die Parallelisierung der Transaktionsausführung innerhalb der EVM. Wir haben Grevm entwickelt, eine parallele EVM-Laufzeit, die die Transaktionsverarbeitung durch die gleichzeitige Ausführung von Transaktionen erheblich beschleunigt. Grevm nutzt Datenabhängigkeits-Hinweise aus der Transaktionssimulation, um die parallele Ausführung zu optimieren, die Anzahl der Transaktionswiederholungen zu reduzieren und den Durchsatz zu steigern.

Grevm (Gravity EVM) - parallele EVM-Ausführung

Grevm ist ein Open-Source-Projekt, das auf GitHub gehostet wird (wenn es noch nicht Open Source ist, wird es in Zukunft Open Source sein). Bitte beachten Sie das README für weitere Informationen.

Grevm (Gravity EVM) ist eine Open-Source-parallele EVM-Laufzeit, die auf revm basiert. Die Algorithmen von Grevm sind vom BlockSTM inspiriert und wurden durch die Einführung von Transaktionsdatenabhängigkeitsgraphen, die aus Simulationsergebnissen gewonnen werden, erweitert. Dieser Mechanismus ermöglicht effizientere Planungen in der parallelen Ausführung, um die Wiederholung von Transaktionen zu minimieren.

In unseren Benchmark-Tests ist Grevm die derzeit schnellste Open-Source-parallele EVM-Implementierung. Für konfliktfreie Transaktionen ist Grevm 4,13-mal schneller als die sequenzielle Ausführung, mit einer Geschwindigkeit von 26,50 gigagas/s. Wenn man eine I/O-Verzögerung von 100 μs in der realen Welt simuliert, ist seine Geschwindigkeit 50,84-mal schneller als die sequenzielle Ausführung, mit einem Durchsatz von 6,80 gigagas/s. Dieser Leistungssprung ist das Ergebnis der Integration von paralleler Ausführung und asynchronen I/O-Operationen - die Parallelisierung ermöglicht es, I/O-Operationen effizient zu überlappen, was weitere Beschleunigungen nach sich zieht.

Die Kernidee von Grevm besteht darin, die Datenabhängigkeiten zwischen Transaktionen zu nutzen, um die parallele Ausführung durch spekulative Transaktions-Lese-/Schreibsammlungen zu optimieren. Obwohl nicht alle Hinweise vollständig genau sind, sind diese auf Simulationen basierenden Hinweise in der Regel praktikabel genug. Zum Beispiel waren auf der Ethereum-Hauptkette etwa 30 % der Transaktionen einfache Ether-Überweisungen, während 25 % bis 30 % ERC20-Token-Überweisungen waren, die in der Regel nur das Lesen und Schreiben einer begrenzten Anzahl von Konten und Speicherplätzen umfassen. Für diese Transaktionen haben die Simulationsergebnisse eine konsistente Genauigkeit.

Basierend auf diesen Erkenntnissen haben wir für Grevm einen dreistufigen parallelen Ausführungsrahmen entwickelt, der als Folgearbeit des Block-STM-Modells dient und Datenabhängigkeits-Hinweise aus Transaktionssimulationen integriert:

· Phase 1: Hinweisgenerierung und Statusvorabladung - Simulation von Transaktionen zur Sammlung von Abhängigkeitshinweisen und zur Vorwärmung des Speichercaches. Diese Phase kann zu verschiedenen Zeitpunkten durchgeführt werden, abhängig vom Design der Blockchain. Wenn beispielsweise neue Transaktionen im Speicherpool ankommen, kann die Simulation sofort ausgeführt werden, um die Abhängigkeitshinweise im Voraus vorzubereiten.

· Phase 2: Abhängigkeitsanalyse - Umwandlung der Abhängigkeitshinweise, die in der Simulationsphase gesammelt wurden, in einen gerichteten azyklischen Graphen (DAG), der die Abhängigkeiten zwischen den Transaktionen darstellt. Dieser DAG wird verwendet, um die Transaktionsplanung in der nachfolgenden parallelen Ausführung zu steuern.

· Phase 3: Parallele Ausführung unter Konfliktlösung - Die Transaktionen werden mithilfe eines modifizierten BlockSTM-Algorithmus auf der Grundlage von Abhängigkeiten im DAG parallel ausgeführt. Der Scheduler wählt die Transaktionen nicht mehr strikt nach der Reihenfolge der Transaktionen im Block (z.B. 1, 2, 3, ..., n) aus, sondern priorisiert die Auswahl der Transaktionen basierend auf dem DAG, um Konflikte zu minimieren und den Bedarf an Wiederholungen zu reduzieren.

Asynchrone Batch-Statusverpflichtung

Die Generierung der Statusverpflichtung bleibt ein kritischer Engpass in der Pipeline der Blockchain, bedingt durch die inhärente Sequenzialität der Merkle-Struktur. Jede Berechnung eines Teilbaums muss abgeschlossen sein, bevor die endgültige Statusverpflichtung generiert werden kann, was zu erheblichen Verzögerungen führen kann. Obwohl bestehende Lösungen (wie die kontenbasierte Parallelisierung von reth) ein gewisses Maß an Parallelität eingeführt haben, gibt es immer noch erheblichen Optimierungsbedarf. Im Kontext der Block Stream Reactor (BSR)-Ausführungsschicht von Gravity reth ermöglicht die Entkopplung des Konsenses der Statusverpflichtung von der Transaktionsausführung die asynchrone Durchführung von verzögerten und batchbasierten Statusverpflichtungsberechnungen, ohne die Ausführung zu blockieren.

Um diese Probleme zu lösen, bringt das vorgeschlagene Framework die folgenden Schlüsselinnovationen ein:

Asynchrone Batch-Hash-Berechnung: Durch die Entkopplung von Statusverpflichtungskonsens und Transaktionsausführung ermöglicht das Framework die asynchrone Berechnung der Statusverpflichtung. Die Aktualisierungen der Statuswurzel erfolgen in Chargen (z. B. einmal alle 10 Blöcke), um die Frequenz der Berechnung der Statuswurzel zu reduzieren. Diese Batch-Verarbeitungsmethode realisiert eine effiziente Hash-Berechnung durch Aggregation gemeinsamer dirty Knoten, um häufige Aktualisierungskosten zu minimieren und die Gesamtkosten der Berechnung zu senken. Für kleine Blöcke kann die Batch-Verarbeitung die Parallelität erheblich erhöhen; für große Blöcke können die Gesamtkosten der Berechnung gesenkt werden.

Vollständige Parallelisierung: Dieses Framework erweitert die Parallelisierung auf den gesamten Statusbaum und nicht nur auf einzelne Kontobäume. Für als "dirty" markierte Knoten verwendet das Framework einen Algorithmus zur parallelen Zustandsberechnung, um den Baum in unabhängige Teilbäume zu unterteilen und diese Teilbäume gleichzeitig zu verarbeiten. Die Ergebnisse werden auf der obersten Ebene aggregiert, um die endgültige Wurzel effizient zu berechnen. Diese Methode stellt sicher, dass große Blöcke mit einer hohen Anzahl von Transaktionen und Zustandsänderungen die Multithread-Nutzung maximieren können, wodurch der Durchsatz maximiert wird.

Alternativer schneller Statuswurzel: Um den Anforderungen des Ethereum-Blockheaders und der BLOCKHASH-Operation (die den Zugriff auf die Statuswurzel der letzten 256 Blöcke erfordert) gerecht zu werden, haben wir die Statuswurzel neu definiert. Anstatt auf die endgültige Statusverpflichtung (die während der Transaktionsausführung nicht verfügbar ist) angewiesen zu sein, berechnen wir die Statuswurzel als Kombination des Hashwerts der Blockänderungssätze und der vorherigen Statuswurzel. Diese Methode beschleunigt die Berechnung der Statuswurzel, da sie nicht auf den Abschluss der vollständigen Statusverpflichtung warten muss.

Gravity Store

Um den Anforderungen an das Datenmanagement von Hochleistungsblockchains gerecht zu werden, entstand Gravity Store als optimierte Mehrversionsspeicherschicht. Es basiert auf dem Design von reth, das das Problem der Statusausdehnung durch die Trennung von Statusverpflichtungsspeicherung und Statusdatenspeicherung verringert hat, während die Lese- und Schreibkosten reduziert werden. Allerdings muss die Ausführungsschicht von Gravity reth weitere Unterstützung für parallele Verarbeitung und asynchrone Statusverpflichtungen bieten, was zusätzliche technische Anforderungen aufwirft.

Um diese Herausforderungen zu bewältigen, hat Gravity Store eine effiziente Mehrversionen-Baumstruktur vorgeschlagen, die speziell für unsere BSR (Block Stream Reactor) Architektur maßgeschneidert ist. Diese Baumstruktur unterstützt die Verwaltung mehrerer Versionen von Statusaktualisierungen. Im Gegensatz zu herkömmlichen Methoden, die Hashwerte sofort nach Änderungen aktualisieren, markiert Gravity Store die geänderten Knoten als "dirty nodes", um die Hashberechnung zu verzögern und Batch-Operationen durchzuführen. Dieses Design ermöglicht die schnelle Erstellung neuer Versionen, effiziente Abfragen von Versionen und die Bereinigung älterer Versionen unterhalb eines bestimmten Höhenwerts, was die Leistung des Statusmanagements der Blockchain erheblich verbessert.

Wir arbeiten auch an der unabhängigen Entwicklung der Speicherengine Gravity DB, deren Designziele darin bestehen, eine optimierte Speicherschicht für Blockchain-Anwendungen bereitzustellen und vollständige asynchrone I/O-Operationen zu unterstützen. Das Design dieser Engine ist von LETUS inspiriert, einer hochleistungsfähigen, logstrukturierten, allgemeinen Datenbank-Engine für Blockchain. Unser leitender Entwickler Richard, einer der Hauptautoren von LETUS, wird in einem bald veröffentlichten Blogbeitrag detaillierte Informationen zu seinem Design bereitstellen.

Fazit

Gravity Chain ist eine leistungsstarke, EVM-kompatible Layer-1-Blockchain, die speziell entwickelt wurde, um den Skalierungs- und Leistungsanforderungen moderner Web3-Anwendungen gerecht zu werden. In Kombination mit Gravity SDK, dem pipeline-basierten AptosBFT PoS-Konsensengine und der von Grevm betriebenen Block Stream Reactor-Ausführungsschicht Gravity reth erreicht Gravity einen Durchsatz von 1 Gigagas pro Sekunde, Untersekunden-Transaktionsbestätigungszeiten und PoS-Sicherheit, die auf Restaking-Mechanismen basiert. Das Design dieser technischen Komponenten bietet eine solide Grundlage für die Schaffung maßgeschneiderter alternativer L1-Blockchains oder effizienter L2-Lösungen für Web3-Anwendungen, insbesondere in Szenarien, die eine Optimierung von EVM-Ketten erfordern.

Dieser Artikel stammt aus einem Beitrag und spiegelt nicht die Ansichten von BlockBeats wider.