Teil I: Designraum für parallele Blockchains

Zusammenfassung: Dieser Forschungsbeitrag bietet einen Überblick über parallele Designarchitekturen für Blockchains unter Verwendung von drei relevanten Beispielen: Solana, Sei und Monad. Es hebt die Unterschiede zwischen optimistischer und deterministischer Parallelisierung hervor und untersucht die Feinheiten des Zustands- und Speicherzugriffs in diesen Ketten.

Einführung

Im Jahr 1837 entwarf der Informatiker und Mathematiker Charles Babbage den „Analytische Maschine,” das die theoretische Grundlage für parallele Berechnungen legte. Heute ist die Parallelisierung ein zentrales Thema in der Kryptowelt, da Blockchains versuchen, die Grenzen von Verarbeitung, Effizienz und Durchsatz zu erweitern.

Das Paralleluniversum

Parallele Berechnung ermöglicht die gleichzeitige Ausführung vieler Berechnungen oder Prozesse, im Gegensatz zur sequentiellen oder nacheinanderen Ausführung von Berechnungen. Paralleles Computing bezieht sich darauf, größere Probleme in kleinere, unabhängige Teile aufzuteilen, die von mehreren Prozessoren ausgeführt werden können, die über gemeinsamen Speicher kommunizieren. Parallele Systeme haben eine Reihe von Vorteilen, wie z.B. erhöhte Effizienz und Geschwindigkeit, Skalierbarkeit, verbesserte Zuverlässigkeit und Fehlertoleranz, bessere Ressourcennutzung und die Fähigkeit, sehr große Datensätze zu verarbeiten.

Es ist jedoch entscheidend zu erkennen, dass die Wirksamkeit der Parallelisierung von den Besonderheiten der zugrunde liegenden Architektur und Implementierung abhängt. Zwei Kernengpässe für Blockchains sind kryptografische Funktionen (Hashfunktionen, Signaturen, elliptische Kurven usw.) und Speicher-/Zustandszugriff. Bei Blockchains liegt eine der Schlüsselkomponenten bei der Gestaltung eines effizienten parallelen Systems in den Feinheiten des Zugriffs auf den Zustand. Der Zustandszugriff bezieht sich auf die Fähigkeit einer Transaktion, auf den Zustand einer Blockchain zuzugreifen und in diesen zu schreiben, einschließlich Speicher, Smart Contracts und Kontostände. Damit eine parallelisierte Blockchain effektiv und leistungsfähig ist, muss der Zustandszugriff optimiert sein.

Derzeit gibt es zwei Denkschulen zur Optimierung des Zustandszugriffs für parallelisierte Blockchains: deterministische Parallelisierung gegenüber optimistischer Parallelisierung. Deterministische Parallelisierung erfordert, dass der Code explizit im Voraus erklärt, welche Teile des Blockchain-Zustands abgerufen und geändert werden. Dies ermöglicht einem System zu bestimmen, welche Transaktionen im Voraus ohne Konflikte parallel verarbeitet werden können. Deterministische Parallelisierung ermöglicht Vorhersagbarkeit und Effizienz (insbesondere, wenn Transaktionen größtenteils unabhängig sind). Es schafft jedoch mehr Komplexität für Entwickler.

Optimistische Parallelisierung erfordert nicht, dass der Code seinen Zustellzugriff im Voraus deklariert und verarbeitet Transaktionen parallel, als ob es keine Konflikte gäbe. Wenn ein Konflikt entsteht, wird die optimistische Parallelisierung entweder erneut ausgeführt, neu verarbeitet oder die konkurrierenden Transaktionen seriell ausgeführt. Während die optimistische Parallelisierung den Entwicklern mehr Flexibilität ermöglicht, ist bei Konflikten eine erneute Ausführung erforderlich, was dazu führt, dass diese Methode am effizientesten ist, wenn Transaktionen nicht in Konflikt stehen. Es gibt keine richtige Antwort darauf, welche dieser Ansätze besser ist. Es handelt sich einfach um zwei verschiedene (und lebensfähige) Ansätze zur Parallelisierung.

Im ersten Teil dieser Serie werden wir zunächst einige Grundlagen nicht-krypto-paralleler Systeme erkunden, gefolgt vom Designraum für parallele Ausführung für Blockchains, wobei wir uns auf drei Kernbereiche konzentrieren:

1. Überblick über Crypto Parallel Systems
2. Ansätze zum Speicher- & Zustandszugriff
3. Parallele Designmöglichkeiten

Non-Crypto Parallel Systems

Basierend auf dem, was wir gerade über das, was parallele Berechnungen ermöglichen und die Vorteile von parallelen Systemen gelesen haben, ist es leicht zu verstehen, warum die Übernahme paralleler Berechnungen in den letzten Jahren Fahrt aufgenommen hat. Die verstärkte Nutzung paralleler Rechenleistung hat in den letzten Jahrzehnten allein viele Durchbrüche ermöglicht.

1. Bildgebung in der Medizin: Die parallele Verarbeitung hat die medizinische Bildgebung grundlegend verändert und zu erheblichen Geschwindigkeits- und Auflösungssteigerungen bei verschiedenen Modalitäten wie MRT, CT, Röntgen und optischer Tomographie geführt. Nvidia steht an vorderster Front dieser Fortschritte und bietet Radiologen verbesserte künstliche Intelligenzfähigkeiten durch ihr Paralleles Verarbeitungstoolkit, das es Bildgebungssystemen ermöglicht, erhöhte Daten- und Rechenlasten effektiver zu bewältigen.
2. Astronomie: Einige neue Phänomene, wie das Verständnis von Schwarzen Löchern, wurden nur durch den Einsatz paralleler Supercomputer möglich gemacht.
3. Unitys Spiel-Engine: Die Engine von Unity nutzt die Fähigkeiten von GPUs, die für massive grafische Arbeitslasten ausgelegt sind, um Leistung und Geschwindigkeit zu verbessern. Die Engine ist mit Multithreading- und parallelen Verarbeitungsfunktionen ausgestattet, die ein nahtloses Spielerlebnis ermöglichen und komplexe, detaillierte Spielumgebungen schaffen.

Lassen Sie uns drei Blockchains untersuchen, die parallele Ausführungsumgebungen implementiert haben. Zuerst werden wir Solana untersuchen, gefolgt von zwei EVM-basierten Ketten, Monad und Sei.

Parallel Design-Übersicht – Solana

Auf hoher Ebene besteht die Designphilosophie von Solana darin, dass die Blockchain-Innovation mit Hardware-Verbesserungen weiterentwickelt werden sollte. Wenn die Hardware im Laufe der Zeit durch das Moore'sche Gesetz verbessert wird, ist Solana so konzipiert, dass es von einer verbesserten Leistung und Skalierbarkeit profitiert. Mitbegründer von Solana Anatoly Yakovenkoursprünglich entworfen Solanas ParallelisierungsarchitekturVor mehr als fünf Jahren, und heute verbreitet sich der Parallelismus als ein Blockchain-Designprinzip schnell.

Solana verwendet deterministische Parallelisierung, die aus Anatolys früheren Erfahrungen mit eingebetteten Systemen stammt, bei denen Sie in der Regel alle Zustände im Voraus deklarieren. Dies ermöglicht es der CPU, alle Abhängigkeiten zu kennen, was es ihr ermöglicht, die erforderlichen Teile des Speichers vorab abzurufen. Das Ergebnis ist eine optimierte Systemausführung, erfordert jedoch erneut, dass Entwickler von Anfang an zusätzliche Arbeit leisten. Auf Solana sind alle Speicherabhängigkeiten für ein Programm erforderlich und werden in der erstellten Transaktion angegeben (d. h. Zugriffslisten), was es der Laufzeit ermöglicht, mehrere Transaktionen parallel effizient zu planen und auszuführen.

Die nächste wichtige Komponente der Solana-Architektur ist die Sealevel-VM, bei der es sich um die parallele Smart-Contract-Laufzeit von Solana handelt. Sealevel unterstützt nativ die parallele Verarbeitung mehrerer Verträge und Transaktionen, basierend auf der Anzahl der Kerne eines Validators. Ein Validator in einer Blockchain ist ein Netzwerkteilnehmer, der für die Verifizierung und Validierung von Transaktionen, das Vorschlagen neuer Blöcke und die Aufrechterhaltung der Integrität und Sicherheit der Blockchain verantwortlich ist. Da Transaktionen im Voraus deklarieren, welche Konten gelesen und geschrieben werden müssen, kann der Solana-Scheduler bestimmen, welche Transaktionen gleichzeitig ausgeführt werden können. Aus diesem Grund ist der "Block Producer" oder Leader bei der Validierung in der Lage, Tausende von ausstehenden Transaktionen zu sortieren und die nicht überlappenden Transaktionen parallel zu planen.

Das letzte Designelement für Solana ist das „pipelining“. Pipelining tritt auf, wenn Daten in einer Reihe von Schritten verarbeitet werden müssen und für jeden Schritt unterschiedliche Hardware verantwortlich ist. Die Hauptidee hierbei ist, Daten, die seriell ausgeführt werden müssen, zu parallelisieren, indem man Pipelining verwendet. Diese Pipelines können parallel ausgeführt werden, und jeder Pipelinestufe kann unterschiedliche Transaktionschargen verarbeiten.

Diese Optimierungen ermöglichen es Sealevel, unabhängige Transaktionen gleichzeitig zu organisieren und auszuführen, wobei die Hardware die Fähigkeit nutzt, mehrere Datenpunkte gleichzeitig mit einem einzigen Programm zu verarbeiten. Sealevel sortiert Anweisungen nach Programm-ID und führt dieselbe Anweisung parallel auf allen relevanten Konten aus.

Mit diesen Innovationen im Hinterkopf können wir sehen, dass Solana absichtlich darauf ausgelegt wurde, Parallelisierung zu unterstützen.

Paralleles Design-Übersicht – Sei

Sei ist eine Open-Source-Layer-1-Blockchain für den Austausch digitaler Vermögenswerte. Sei V2 nutzt die optimistische Parallelisierung und ist daher benutzerfreundlicher als ihr deterministisches Gegenstück. Bei der optimistischen Parallelisierung können Smart Contracts nahtloser und gleichzeitig ausgeführt werden, ohne dass Entwickler ihre Ressourcen im Voraus deklarieren müssen. Dies bedeutet, dass die Kette optimistisch alle Transaktionen parallel ausführt. Wenn es jedoch zu Konflikten kommt (d. h. mehrere Transaktionen, die auf denselben Status zugreifen), behält die Blockchain den spezifischen Speicherbestandteil im Auge, auf den jede konkurrierende Transaktion Auswirkungen hat.

Seis Blockchain-Ansätze führen Transaktionen unter Verwendung von „Optimistic Concurrency Control (OCC)“ aus. Das gleichzeitige Transaktionsverarbeitung erfolgt, wenn mehrere Transaktionen gleichzeitig in einem System aktiv sind. Es gibt zwei Phasen in diesem Transaktionsansatz: Ausführung und Validierung.

In der Ausführungsphase werden Transaktionen optimistisch verarbeitet, wobei alle Lese-/Schreibvorgänge vorübergehend in einem transaktionsspezifischen Speicher abgelegt werden. Anschließend durchläuft jede Transaktion die Validierungsphase, in der die Informationen in den temporären Speicheroperationen auf etwaige Zustandsänderungen geprüft werden, die durch vorherige Transaktionen vorgenommen wurden. Ist eine Transaktion unabhängig, läuft sie parallel. Liest eine Transaktion jedoch Daten, die von einer anderen Transaktion geändert wurden, entsteht ein Konflikt. Seis paralleles System identifiziert jeden Konflikt, indem es die Lesevorgänge von Transaktionen mit den neuesten Zustandsänderungen in einem Mehrversionenspeicher vergleicht (diese sind nach Transaktionsreihenfolge indiziert). Sei wird Instanzen, in denen Konflikte auftreten, erneut ausführen und überprüfen. Dies ist ein iterativer Prozess, der Ausführung, Validierung und erneutes Ausführen umfasst, um die Konflikte zu beheben. Die Grafik unten veranschaulicht Seis Ansatz für Transaktionen, wenn ein Konflikt auftritt.

Quelle: https://blog.sei.io/sei-v2-the-first-parallelized-evm/

Seis Implementierung führt zu günstigeren Gasgebühren und einem breiteren Designraum für EVM-Entwickler. Historisch gesehen waren EVM-Umgebungen auf <50 TPS beschränkt, was Entwickler zwang, Anwendungen zu erstellen, die Anti-Muster folgten. Sei V2 ermöglicht es Entwicklern, sich Sektoren zu nähern, die typischerweise hohe Leistung und niedrige Gebühren erfordern, wie DeFi, DePIN und Gaming.

Parallele Designübersicht - Monad

Monad baut eine parallele EVM Layer 1 mit voller Bytecode-Kompatibilität auf. Was Monad einzigartig macht, ist nicht nur sein Parallelisierungs-Engine, sondern auch das, was sie unter der Haube gebaut haben, um es zu optimieren. Monad verfolgt einen einzigartigen Ansatz in Bezug auf sein Gesamtdesign, indem mehrere Schlüsselfunktionen, einschließlich Pipeline-Verarbeitung, asynchrone I/O, Trennung von Konsens und Ausführung, integriert werden.MonadDB.

Eine Schlüsselinnovation im Design von Monad ist pipeliningmit einem leichten Offset. Der Offset ermöglicht es, mehr Prozesse zu parallelisieren, indem mehrere Instanzen gleichzeitig ausgeführt werden. Daher wird Pipelining verwendet, um eine Reihe von Funktionen zu optimieren, wie beispielsweise Pipelining beim Zugriff auf den Zustand, Pipelining bei der Transaktionsausführung, Pipelining innerhalb von Konsens und Ausführung sowie Pipelining innerhalb des Konsensmechanismus selbst.

Als nächstes werden wir uns das Parallelisierungsstück von Monad genauer ansehen. In Monad sind Transaktionen innerhalb des Blocks linear geordnet, aber das Ziel ist es, diesen Endzustand schneller zu erreichen, indem die parallele Ausführung genutzt wird. Monad verwendet einen optimistischen Parallelisierungsalgorithmus für das Design seines Ausführungsmotors. Der Motor von Monad verarbeitet Transaktionen gleichzeitig und führt dann eine Analyse durch, um sicherzustellen, dass das Ergebnis identisch wäre, wenn die Transaktionen nacheinander ausgeführt würden. Bei Konflikten müssen Sie die Ausführung erneut ausführen. Die parallele Ausführung hier ist ein relativ einfacher Algorithmus, aber die Kombination mit den anderen Schlüsselinnovationen von Monad macht diesen Ansatz neuartig. Ein Punkt, der hier zu beachten ist, ist, dass selbst wenn eine erneute Ausführung erfolgt, dies in der Regel günstig ist, da die für eine ungültige Transaktion benötigten Eingaben fast immer im Cache verbleiben, sodass es sich um eine einfache Cache-Suche handelt. Die Wiederholung der Ausführung ist garantiert erfolgreich, da Sie die vorherigen Transaktionen im Block bereits ausgeführt haben.

Monad verbessert auch die Leistung, indem Ausführung und Konsens getrennt werden, ähnlich wie bei Solana und Sei, zusätzlich zur verzögerten Ausführung. Die Idee hier ist, dass, wenn Sie die Bedingung für die Ausführung lockern, um bis zur Fertigstellung des Konsenses abgeschlossen zu sein, können Sie beide parallel ausführen, was zusätzliche Zeit für beides bedeutet. Natürlich verwendet Monad einen deterministischen Algorithmus, um diese Bedingung zu behandeln, um sicherzustellen, dass einer von ihnen nicht zu weit vorausläuft, ohne die Möglichkeit einzuholen.

Einzigartige Ansätze zum Zugriff auf den Zustand und den Speicher

Wie ich am Anfang dieses Beitrags erwähnt habe, ist der Zugriff auf den Zustand einer der typischen Leistungsengpässe für Blockchains. Die Designentscheidungen rund um den Zustandszugriff und den Speicher können letztendlich bestimmen, ob eine spezifische Implementierung eines parallelen Systems die Leistung in der Praxis verbessern wird. Hier werden wir die verschiedenen Ansätze von Solana, Sei und Monad entpacken und vergleichen.

Solana State Access: AccountsDB / Cloudbreak

Solana nutzt die horizontale Skalierung, um Zustandsdaten auf mehreren SSD-Geräten zu verteilen und zu verwalten. Viele Blockchains verwenden heute generische Datenbanken (z. B. LevelDB) mit Einschränkungen bei der Behandlung einer großen Anzahl gleichzeitiger Lese- und Schreibvorgänge von Zustandsdaten. Um dies zu vermeiden, hat Solana ihr eigenes benutzerdefiniertes AccountsDB entwickelt, das aufCloudbreak.

Cloudbreak ist für den parallelen Zugriff über I/O-Operationen konzipiert, anstatt sich ausschließlich auf RAM zu verlassen, was von Natur aus schnell ist. I/O-Operationen (Input/Output) beziehen sich auf das Lesen von Daten aus oder das Schreiben von Daten auf eine externe Quelle, wie z. B. eine Festplatte, ein Netzwerk oder ein Peripheriegerät. Anfangs verwendete Cloudbreak einen In-RAM-Index zur Zuordnung von öffentlichen Schlüsseln zu Konten, die über Guthaben und Daten verfügen. Zum Zeitpunkt des Verfassens dieses Papiers und der Version 1.9 wurde der Index jedoch aus dem RAM auf SSDs verschoben. Diese Verschiebung ermöglicht es Cloudbreak, gleichzeitig 32 (I/O)-Operationen in seiner Warteschlange zu verarbeiten und die Durchsatzleistung über mehrere SSDs zu verbessern. Folglich können Blockchain-Daten wie Konten und Transaktionen effizient abgerufen werden, als ob sie sich im RAM befänden und memory-mapped-Dateien verwendet würden. Die folgende Grafik stellt eine anschauliche Speicherhierarchie dar. Obwohl RAM schneller ist, hat es weniger Kapazität als SSD und ist in der Regel teurer:

Veranschauliches Speicherhierarchiediagramm

Durch horizontale Skalierung und die Verteilung von Statusdaten auf mehrere Geräte reduziert Cloudbreak die Latenzzeit und verbessert Effizienz, Dezentralisierung und Netzwerksicherheit innerhalb des Solana-Ökosystems.

Sei State Zugriff: SeiDB

Sei hat seine Speicher neu gestaltet, SeiDB, um mehrere Probleme anzusprechen: Schreibverstärkung (wie viel Metadaten benötigt wird, um Datenstrukturen zu pflegen, kleiner = besser), Zustandsaufblähung, langsame Operationen und Leistungsverschlechterung im Laufe der Zeit. Die neue Neugestaltung ist nun in zwei Komponenten unterteilt: Zustandsspeicher und Zustandsbestätigung. Das Aufzeichnen und Überprüfen aller Änderungen an Daten erfolgt durch die Zustandsbestätigung, während die Datenbank, die zu jedem Zeitpunkt alle Daten erfasst, durch den Zustandsspeicher (SS) gehandhabt wird.

In Sei V2 wird die Zustandsverpflichtung über einen speicherzugriff abgebildet IAVL-Baumarchitektur (MemIAVL)Der speicherkartierte IAVL-Baum speichert weniger Metadaten, was den Zustandsspeicher und die Zustandssynchronisierungszeiten reduziert und das Ausführen eines vollständigen Knotens erheblich erleichtert. Der speicherkartierte IAVL-Baum wird auf der Festplatte als drei Dateien (kv, branch, leaves) dargestellt; daher müssen weniger Metadaten verfolgt werden, was dazu beiträgt, den Zustandsspeicher um über 50% zu reduzieren. Die neue MemIAVL-Struktur hilft dabei, den Schreibanstiegsfaktor zu reduzieren, da sie die für die Aufrechterhaltung der Datenstrukturen erforderlichen Metadaten reduziert.

Das aktualisierte SeiDB ermöglicht eine flexible Unterstützung für das Datenbank-Backend für die Zustandsspeicherschicht. Sei glaubt, dass unterschiedliche Knotenbetreiber unterschiedliche Anforderungen und Speicherbedürfnisse haben werden. Daher wurde das SS so konzipiert, dass es verschiedene Backends unterstützt, wodurch den Betreibern Freiheit und Flexibilität geboten wird, z. B. PebbleDB, RocksDB, SQLite usw.

Zugriffszustand: MonadDB

Es gibt einige wichtige Feinheiten beim Zugriff auf den Zustand von Monad. Zunächst nutzen die meisten Ethereum-Clients zwei Arten von Datenbanken: B-Baum-Datenbanken (z.B. LMDB) oder protokollierte Zusammenführungsbaum (LSM) Datenbanken (z.B. RocksDB, LevelDB). Beide sind generische Datenstrukturen, die nicht explizit für Blockchains entwickelt wurden. Darüber hinaus nutzen diese Datenbanken nicht die aktuellsten Fortschritte in der Linux-Technologie, insbesondere in Bezug auf asynchrone Operationen und I/O-Optimierungen. Schließlich verwaltet Ethereum selbst den Zustand mithilfe Patricia Merkle Trie, das sich auf Kryptographie, Verifizierung und Beweise spezialisiert. Das Hauptproblem besteht darin, dass Kunden diesen spezifischen Patricia-Merkle-Baum in allgemeinere Datenbanken (d. h. B-Baum / LSM) integrieren müssen, was zu erheblichen Leistungseinbußen wie übermäßigem Festplattenzugriff führt.

All das oben Genannte trägt dazu bei, warum Monad sich entschieden hat, seine individuell entwickelte MonadDB-Datenbank zu erstellen, die speziell für die effiziente Verarbeitung von Blockchain-Daten und Zustandszugriff konzipiert ist. Zu den wichtigsten Funktionen von MonadDB gehören eine paralleler Datenbankzugriff, eine individuell optimierte Datenbank für Merkle Trie-Daten, effizienter Zustandszugriff über die Standard-RAM-Nutzung sowie Dezentralisierung und Skalierbarkeit.

MonadDB ist explizit für Blockchains konzipiert, was es performanter macht als die Verwendung generischer Datenbanken. Das benutzerdefinierte MonadDB ist spezialisiert und maßgeschneidert für die effiziente Verwaltung von Merkle-Trie-Daten und ermöglicht den parallelen Zugriff auf mehrere Trie-Knoten gleichzeitig. Obwohl die Kosten für einen einzelnen Lesevorgang bei MonadDB im Vergleich zu einigen der oben aufgeführten generischen Datenbanken gleich sind, ist hier die entscheidende Eigenschaft, dass MonadDB viele Lesevorgänge parallel ausführen kann, was zu einer massiven Beschleunigung führt.

MonadDB ermöglicht den gleichzeitigen Zugriff auf den parallelen Zugriff auf die Datenbank. Da Monad diese Datenbank von Grund auf aufbaut, kann es die aktuellsten Linux-Kernel-Technologien und die volle Leistung von SSDs für asynchrones I/O nutzen. Mit async I/O sollte, wenn eine Transaktion einen Lesezustand von der Festplatte erfordert, dies die Operationen nicht stoppen, die auf die Fertigstellung warten. Stattdessen sollte es das Lesen beginnen und gleichzeitig die Verarbeitung anderer Transaktionen fortsetzen. So beschleunigt async I/O die Verarbeitung von MonadDB erheblich. Monad kann eine bessere Leistung aus der Hardware extrahieren, indem es die Nutzung von SSD optimiert und die Abhängigkeit von übermäßigem RAM reduziert. Dies hat den zusätzlichen Vorteil, sich mit Dezentralisierung und Skalierbarkeit zu verbinden.

Zusammenfassung der Vergleiche für Solana vs. Sei vs. Monad

Fazit

Abschließend bietet die Erkundung der Parallelisierung in Blockchains durch die Brille von Solana, Sei und Monad ein umfassendes Verständnis dafür, wie verschiedene Architekturen und Ansätze die Leistung und Skalierbarkeit verbessern können. Die deterministische Parallelisierung von Solana mit dem Schwerpunkt auf der vorherigen Deklaration des Zustandszugriffs bietet Vorhersehbarkeit und Effizienz und macht sie zu einer leistungsstarken Wahl für Anwendungen, die eine hohe Durchsatzrate erfordern. Andererseits priorisiert der optimistische Parallelisierungsansatz von Sei die Entwicklerflexibilität und eignet sich gut für Umgebungen, in denen Transaktionskonflikte selten auftreten. Mit seiner einzigartigen Kombination aus optimistischer Parallelisierung und dem individuell entwickelten MonadDB bietet Monad eine innovative Lösung, die die neuesten technologischen Fortschritte nutzt, um den Zustandszugriff und die Leistung zu optimieren.

Jede Blockchain verfolgt einen eigenen Ansatz zur Bewältigung der Herausforderungen der Parallelisierung, mit ihren eigenen Kompromissen. Solanas Design zielt darauf ab, die Hardwareauslastung und Durchsatz zu maximieren, während sich Sei auf die Vereinfachung des Entwicklungsprozesses konzentriert und Monad auf eine maßgeschneiderte Datenbanklösung für Blockchain-Daten setzt. Diese Unterschiede verdeutlichen die Vielfalt im Blockchain-Ökosystem und die Bedeutung der Auswahl der richtigen Plattform basierend auf den spezifischen Anforderungen der Anwendung.

Da sich der Bereich der Blockchain weiterentwickelt, werden die Fortschritte bei den Parallelisierungstechniken, die von Solana, Monad und Sei demonstriert werden, zweifellos weitere Innovationen inspirieren. Der Weg zu effizienteren, skalierbaren und für Entwickler freundlicheren Blockchains ist noch lange nicht abgeschlossen, und die aus diesen Plattformen gewonnenen Erkenntnisse werden eine entscheidende Rolle bei der Gestaltung der Zukunft der Blockchain-Technologie spielen.

Im zweiten Teil dieser Serie werden wir uns mit den wirtschaftlichen Auswirkungen und Kompromissen befassen, die mit diesen parallelen Design-Systemen verbunden sind.

Haftungsausschluss：

1. Dieser Artikel ist abgedruckt von [Reziproke Ventures], Alle Urheberrechte liegen beim ursprünglichen Autor [Ali Sheikh]. Wenn Einwände gegen diesen Nachdruck bestehen, wenden Sie sich bitte an den Gate LearnTeam, und sie werden sich schnell darum kümmern.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, 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, Verteilen oder Plagiieren der übersetzten Artikel untersagt.