Shardeum-Start: Eine bahnbrechende Leistung
KI-generierte Bilder
Am Montag, den 27. Januar 2024, ereignete sich in der Welt von web3 ein bahnbrechendes Ereignis, das mit der historischen Leistung eines Raumschiffs verglichen werden kann, das nach seiner ersten Flugtestmission perfekt zu seiner Startrampe zurückkehrte. In diesem außergewöhnlichen Szenario stand Shardeum nicht nur vor großen Herausforderungen, sondern ging auch als Sieger hervor, da seine Netzwerkstabilität das erste Mal war, dass sich ein Sharde-Netzwerk im Bereich der Distributed-Ledger-Technologie selbst heilen konnte.
So wie eine Raumschiffreise sorgfältige Planung, Präzisionstechnik und die reibungslose Ausführung komplexer Manöver erfordert, erforderte die Wiederherstellung des Sphinx-Betanetzes von Shardeum, das einen schweren Absturz erlitten hatte, ein gleichermaßen hohes Maß an technologischer Beherrschung und Innovation. Die Fähigkeit, alle Daten in einem Netzwerk beizubehalten, insbesondere in einem Netzwerk, das mit dynamischem State Sharding arbeitet, ist bahnbrechend.
Während wir uns auf diese Erkundung begeben, feiern wir nicht nur die bahnbrechende Landung von Shardeum, sondern erkennen darin auch einen Wendepunkt in der Entwicklung der Web3-Technologie – „einen Sprung, der die Grenzen der IT-Netzwerkstabilität und Datenintegrität neu definieren könnte.“
Das erste Shard-Netzwerk, das Daten unabhängig wiederherstellt und speichert
Die dynamische Wartung und Wiederherstellung eines Shard-Netzwerks wie Shardeum umfasst eine Reihe komplexer technischer Herausforderungen, die es von herkömmlichen Blockchain-Netzwerken wie Bitcoin oder Ethereum unterscheiden. In einer dynamisch ausgedrückten Shard-Umgebung mit automatischer Skalierung ist die kontinuierliche Neuzuweisung und Verteilung von Knoten und Ressourcen auf verschiedene Shards von entscheidender Bedeutung für die Optimierung von Leistung und Skalierbarkeit. Diese ständigen Änderungen in der Netzwerkarchitektur erhöhen die Komplexität bei der Aufrechterhaltung der Datenkonsistenz, der Gewährleistung der Netzwerkstabilität und der Erleichterung einer effektiven Fehlerbeseitigung erheblich.
Die Bedeutung dieser Herausforderung wird deutlich, wenn man die Reaktion von Shardeum auf Knotenschwankungen mit Bitcoin vergleicht. Das Bitcoin-Netzwerk behält seine Funktionalität auch bei einer kleinen Anzahl von Knoten bei, da jeder aktive Knoten über einen vollständigen Status- und Transaktionsverlauf verfügt. Im Gegensatz dazu verfügt jeder aktive Knoten auf Shardeum aufgrund des Shardeum-Shard-Netzwerks nicht über einen vollständigen Status- und Transaktionsverlauf, und jeder Validator verfügt nur über einen Teil des Gesamtstatus. Die Folge dieses Shardings ist, dass alle Validatorknoten sehr leichtgewichtig werden. Daraus ergeben sich zahlreiche technische Möglichkeiten und Herausforderungen. Wie stellen wir sicher, dass alle Daten erhalten bleiben, wenn ein Knoten ausfällt? Shardeum hat zwei Hauptwege.
Erstens verwendet Shardeum dynamisches State-Sharding, bei dem der gesamte Adressraum entsprechend der Anzahl der aktiven Knoten partitioniert (oder geteilt) wird. Jeder Knoten ist für die ihm zugewiesene Partition verantwortlich, zusammen mit einem bestimmten Radius (R) um ihn herum und zusätzlichen Partitionen (E) daneben, wodurch dynamische Anpassungsfähigkeit und starke Datenredundanz innerhalb des Netzwerkrahmens gewährleistet werden. Selbst wenn also ein Knoten ausfällt, besteht weiterhin Netzwerkkontinuität und es gehen keine Daten verloren.
Zweitens verwendet Shardeum Archivknoten, um den vollständigen Zustand des gesamten Netzwerks zu speichern. Dies wird dadurch erreicht, dass aktive Knoten den teilweise gespeicherten Zustand zur Erfassung an den Archiver streamen. Aufgrund dieser beiden Faktoren und der Designoptimierung muss die Wiederherstellung solcher Netzwerke auf neue Weise gestaltet werden, um weiterhin nützliche Funktionen wie automatische Skalierung und lineare Skalierung zu ermöglichen.
Absturz verstehen
Nachdem wir nun die Grundlagen des Dynamic State Sharding verstanden haben und wissen, dass Archivierungsknoten irgendwie beteiligt sind, wollen wir einige der zusätzlichen Komponenten genauer aufschlüsseln und erläutern. Um den Absturz und die Wiederherstellung von Shardeum Betanet zu verstehen, müssen wir zunächst ein wenig über Folgendes wissen:
Archiver-Knoten
Erkennen Sie fehlende Archivierer
Netzwerkmodus
Wiederherstellungsmodus
Bevor wir uns mit den beteiligten Fehlern befassen, ist es wichtig, die Grundlagen jedes dieser Punkte zu verstehen. Werfen wir also einen Blick darauf!
Archivknoten: Inter Stellar Storage
In Shardeum stellen Archivierungsknoten, auch Archiver genannt, eine sehr wichtige Kategorie von Knoten dar, deren Aufgabe es ist, den gesamten Status und die historischen Aufzeichnungen des Netzwerks zu speichern. Im Gegensatz zu aktiven Knoten nehmen Archivierer nicht am Konsensprozess teil; Seine Hauptfunktion besteht in der umfassenden Archivierung aller Netzwerkdaten, einschließlich Transaktionen und Belege. Der Beitrag des Archivierungsknotens ist entscheidend für die Aufrechterhaltung der Integrität des Netzwerks und die Sicherstellung eines reibungslosen Betriebsablaufs. Dadurch wird der Status von Shardeum als starkes, vollständiges und zuverlässiges Netzwerk bestätigt. Da Archivierer ein integraler Bestandteil seines Netzwerks sind, muss Shardeum über Protokolle verfügen, um nicht reagierende Archivierer (und Validatoren) zu erkennen.
Erkennung verlorener Archive: Außerirdische Technologie enthüllt
Shardeum verfügt über ein Protokoll namens „Lost Node Detection Protocol“, das erkennt, wenn ein aktiver Knoten nicht mehr funktionsfähig ist. Dies ist nur für aktive Knoten gedacht. Allerdings verfügt Shardeum auch über ein Protokoll für Archivierer, das etwas Ähnliches tut, nämlich die Erkennung fehlender Archivierer. Bei der Erkennung fehlender Archiver handelt es sich um ein spezielles Protokoll, das den seltenen Fall bewältigen soll, dass einer oder mehrere Archiver nicht mehr funktionieren und als fehlend markiert werden. Da Archivierungsknoten für die Aufrechterhaltung der Integrität und Zugänglichkeit historischer Daten im Netzwerk von entscheidender Bedeutung sind, ist es daher wichtig, dass diese kritischen Ereignisse erfasst werden können, falls sie nicht mehr reagieren oder eine Fehlfunktion aufweisen, um nachgelagerte Auswirkungen abzuschwächen. Obwohl ein fehlender Archiver diesen speziellen Absturz nicht verursacht, ist es die Interaktion zwischen dem Protokoll zur Erkennung fehlender Archiver und dem jeweiligen Netzwerkmodus. Schauen wir uns nun an, welche Netzwerkmodi es in Shardeum gibt.
Netzwerkmodus auf Shardeum: Keine NASA erforderlich
Die wichtigste Innovation in Shardeum, die vom zugrunde liegenden Shardus-Protokoll unterstützt wird, ist das Netzwerkmodus-Framework. Diese Modi gehen über die grundlegenden Betriebsbedingungen hinaus und realisieren eine komplexe Koordination verschiedener Knotenaktivitäten, Datensynchronisationsmethoden und Transaktionsverwaltungssysteme. Eine solche Netzwerkkonfiguration spielt eine wichtige Rolle bei der Aufrechterhaltung der Betriebsintegrität des Netzwerks, insbesondere in Szenarien, die durch den Verlust von Knoten und Daten gekennzeichnet sind – da Shardeum ein Netzwerk aus Shards ist.
Auf einer einfacheren Ebene lässt sich der Netzwerkmodus in Shardeum am besten als ein gut codierter Notfallplan verstehen, der die Kontinuität des Betriebs für das gesamte Netzwerk ermöglicht – selbst unter unwahrscheinlichen Bedingungen wie Netzwerkabstürzen oder einer netzwerkweiten Verschlechterung. Diese vorprogrammierte betriebliche Belastbarkeit und Widerstandsfähigkeit stellen sicher, dass Shardeum immer am Leben bleibt – egal mit welchen Schwierigkeiten das Netzwerk konfrontiert ist.
Das Verständnis von Fehlern erfordert zwar nicht das Verständnis aller Aspekte des Netzwerkmodus-Frameworks, es ist jedoch hilfreich, die Grundlagen zu kennen. Der Kern des Netzwerkmodus-Frameworks ist die Integration mehrerer verschiedener Netzwerkphasen: Einrichtung, Verarbeitung, Sicherheit, Wiederherstellung, Neustart, Wiederherstellung und Ausfall. Diese Modi wurden sorgfältig entwickelt, um verschiedenen Netzwerksituationen und Notfällen gerecht zu werden. Der Modus, mit dem wir uns in diesem Artikel befassen, ist jedoch der Wiederherstellungsmodus.
KI-generierte Bilder
Reverse Engineering-Wiederherstellungsmodus: Rosewell Revisited
Der Wiederherstellungsmodus ist einer der sieben oben genannten Netzwerkmodi. Der Wiederherstellungsmodus wird eingeleitet, wenn die Anzahl der aktiven Netzwerkknoten unter einen vorgegebenen kritischen Schwellenwert fällt (derzeit auf 75 % oder weniger konfiguriert). Dieser Schwellenwert kann je nach Netzwerkanforderungen angepasst werden. In diesem Modus unterbricht das Netzwerk die Verarbeitung von Anwendungstransaktionen und die Synchronisierung von Anwendungsdaten. Diese Strategie soll die Netzwerkerweiterung erleichtern, indem inaktive Knoten im Rahmen der Knotenrotation nahtlos durchlaufen werden, wodurch die Anzahl der aktiven Knoten auf ein optimales Niveau zurückgeführt wird, idealerweise über 100 %.
Im Wiederherstellungsmodus ermöglicht die Netzwerkarchitektur von Shardeum schrittweise Knoten-Upgrades, die auf ein Wachstum von 20 % pro Zyklus begrenzt sind (jeder Zyklus dauert etwa 60 Sekunden). Diese kontrollierte Wachstumsrate ist entscheidend für die Aufrechterhaltung der Netzwerkstabilität und die Gewährleistung einer reibungslosen Integration neuer Knoten. Ein schneller Anstieg der Anzahl der Knoten, beispielsweise ein Anstieg um 50 %, kann das Netzwerk destabilisieren und den Integrationsprozess erschweren.
Jeder neu hinzugefügte Knoten benötigt Netzwerkressourcen für die Synchronisierung und Integration. Durch die Begrenzung der Upgrades auf 20 % pro Zyklus stellt das Netzwerk sicher, dass seine Infrastruktur das Hinzufügen neuer Knoten ohne Belastung angemessen unterstützen kann. Dieser Ansatz gewährleistet nicht nur die Netzwerkstabilität, sondern minimiert auch das Risiko von Dateninkonsistenzen oder Fehlern während des Synchronisierungsprozesses und sorgt so für die Integrität der Zykluskettendaten.
Hauptursachen für Abstürze: Ereignishorizont
Es ist wichtig zu beachten, dass es zwei verschiedene Fehler gibt. Neon-Bibliotheksfehler – „der dazu führte, dass Validatoren zufällig abstürzten, und ein Fehler im fehlenden Archiver-Erkennungsprotokoll – der eine leere Validatorliste nicht akzeptierte. Obwohl es der Fehler im fehlenden Archiver-Erkennungsprotokoll ist, der zum Absturz der aktuellen Version von Betanet führt, möchte ich Sie einladen, zuerst den Fehler in der Neon-Bibliothek zu besprechen.
In Sphinx Version 1.9.1 haben wir ein Update in die Bibliothek integriert, das den Neon-Binder verwendet, um Rust- und TypeScript-Funktionen zu verknüpfen, da Shardeum hauptsächlich in TypeScript erstellt wird. Neon ist bekannt für seinen innovativen, wenn auch experimentellen Ansatz, der oft die Grenzen herkömmlicher Softwareentwicklungspraktiken überschreitet. Ziel dieser Integration ist es, die Interoperabilität zwischen diesen beiden Sprachen zu verbessern und eine effizientere und direktere Kommunikation innerhalb unserer Softwarearchitektur zu ermöglichen. Dies führt jedoch zu einem Fehler, der dazu führt, dass Knoten zufällig aus dem Netzwerk ausscheiden.
Zweitens wurde bei dem jüngsten Vorfall, der einen Betanet-Absturz auf Shardeum verursachte, als Grundursache eine kritische Anomalie identifiziert, die aus der Interaktion zwischen den beiden oben genannten unterschiedlichen Subsystemen stammt: dem fehlenden Archiver-Erkennungsmechanismus und dem Protokoll für den Netzwerkwiederherstellungsmodus.
Dieser kurze Absturz wurde durch die gleichzeitige Aktivierung dieser beiden Mechanismen ausgelöst, ein Szenario, das noch nie zuvor aufgetreten oder getestet wurde. Der Prozess „Verlorenes Archiv“ wird in Verbindung mit dem Netzwerkwiederherstellungs-Mod und aufgrund eines Fehlers im Modus „Verlorenes Archiv“ ausgelöst, der eine leere Liste aktiver Knoten nicht akzeptiert. Dies führt zu einem Netzwerkabsturz.
Erholungschroniken: Vom systemischen Schock zum stellaren Erwachen
Was ist also eigentlich passiert und wann? Eine Zeitleiste der Ereignisse im Zusammenhang mit dem Netzwerkabsturz und seiner Lösung ist wie folgt:
Sicherheitslücken und erstes Upgrade: Das Netzwerk weist eine Sicherheitslücke auf, die durch den Linting-Prozess 1.9.1 in der npm-Bibliothek (neon) gemeldet wird. Zur Behebung dieses Problems wurde eine Verbesserung implementiert. Diese Verbesserung löste jedoch versehentlich eine Ausnahme aus, die beim lokalen Testen nicht reproduziert wurde.
Zeitweilige Bibliotheksausnahmen, die zu Ausfällen des Validators führen: In der Bibliothek neon kommt es zu sporadischen Ausnahmen, die zu regelmäßigen Ausfällen des Netzwerkvalidators führen. Obwohl das Netzwerkdesign durch das Nachfüllen dieser Validatoren Ausfallsicherheit ermöglicht, lösen leider gleichzeitige Ausfallzeiten bei mehreren Validatoren den Netzwerkwiederherstellungsmodus aus.
Auslösen des Netzwerkwiederherstellungsmodus: Im Netzwerkwiederherstellungsmodus muss das Protokoll die Liste der aktiven Knoten bereinigen und neu erstellen. Ein gleichzeitiger Fehler im fehlenden Ablagesystem, das keine leere Validatorliste unterstützte, war die Hauptursache für den Netzwerkabsturz.
Netzwerkauflösung und -wiederherstellung: Der Absturz wurde behoben und das Netzwerk wurde mithilfe der im Archiver gespeicherten Daten erfolgreich wiederhergestellt. Dies ist das erste Mal in der Geschichte, dass ein abgestürztes Layer-1-Shard-Netzwerk erfolgreich wiederhergestellt werden konnte und alle Daten im Netzwerk intakt blieben. Dies wurde noch nie in einem Netzwerk durchgeführt, geschweige denn in einem Netzwerk mit dynamischem State Sharding. Dieser Erfolg markiert eine erfolgreiche „Raketenlandung“ im Hinblick auf die Netzwerkwiederherstellung.
Abgeschlossene Korrekturen: Erste Korrekturen wurden implementiert, um Bibliotheksprobleme zu beheben, aber in einem kontinuierlichen Bemühen, die Netzwerkstabilität zu verbessern, wurde Version 1.9.5 veröffentlicht. Mit diesem Update wird eine einzelne, aber wichtige Fehlerbehebung eingeführt, die einen weiteren Absturz der Neon-Bindung behebt und die spezifische Schwachstelle lokalisiert und behebt, ohne dass ein netzwerkweites Upgrade erforderlich ist. Zunächst haben Benutzer, die mit Version 1.9.4 arbeiten, die Flexibilität, auf der aktuellen Version zu bleiben oder sich für ein Upgrade auf 1.9.5 zu entscheiden, basierend auf ihrer Einschätzung der Netzwerkleistung und Stabilitätspräferenzen. Letztendlich wurde jedoch entschieden, dass zur Verbesserung der Netzwerkstabilität und zur Behebung anhaltender Probleme im Zusammenhang mit der Neon-Bindung die für den Validator erforderliche Mindestversion auf 1.9.5 erhöht werden sollte. Ziel dieses Updates ist es, Validatoren, die auf Version 1.9.4 laufen und aufgrund der oben genannten Neon-Bindungskomplikationen als anfällig für Abstürze identifiziert wurden, systematisch auszuschließen. Dies ist notwendig, um sicherzustellen, dass der Neon-Bug vollständig entfernt und vollständig behoben wurde.
Da wir nun über den Zeitplan und den Ablauf der großen Ereignisse Bescheid wissen, werfen wir einen Blick auf das Geschehen, damit das Netzwerk schnell wiederhergestellt werden kann.
Auf dem Weg zur Erholung
Agile Wiederherstellung
Die Netzwerkwiederherstellung besteht aus vielen Teilen, aber einer der wichtigsten ist der Shardeum-Wiederherstellungsmodus. Wie bereits erwähnt, wird der Wiederherstellungsmodus eingeleitet, wenn die Anzahl der aktiven Netzwerkknoten unter einen vorgegebenen kritischen Schwellenwert fällt, und ermöglicht ein schnelles, kontrolliertes und effektives Netzwerkwachstum auf sichere Weise zur Wiederherstellung des Netzwerks. Es ist wichtig zu betonen, dass Shardeum ohne den technologischen Einfallsreichtum der Netzwerkmodus-Designer und -Entwickler nicht in der Lage gewesen wäre, sich so leicht von dem Absturz zu erholen und auch seine Innovationskraft unter Beweis zu stellen.
Darüber hinaus hat das Technologieteam von Shardeum erhebliche Anstrengungen unternommen, um Sofortmaßnahmen einzuleiten. Der erste Schritt umfasste eine gründliche Analyse, um die Grundursache des Absturzes zu ermitteln, die auf eine Anomalie in der Interaktion zwischen der Erkennung fehlender Archive des Netzwerks und seinem Wiederherstellungsmodussystem zurückgeführt werden konnte. Da das Team die Komplexität des Problems erkannte, implementierte es schnell einen vielschichtigen Ansatz, um die unmittelbaren Auswirkungen und zugrunde liegenden Schwachstellen anzugehen.
Gemischte Reaktion vom Shardeum Technology Team
Technisch gesehen war die Reaktion gemischt: Zunächst isolierte das Team die betroffenen Komponenten, um einen weiteren Gewebeabbau zu verhindern. Gleichzeitig haben sie einen Patch eingespielt, um einen Fehler im fehlenden Ablagesystem zu beheben und sicherzustellen, dass es mit einer leeren Validatorliste umgehen kann – einem kritischen Fehler, der den Netzwerkausfall ausgelöst hat. Um die volle Betriebsfähigkeit des Netzwerks wiederherzustellen, werden die im Archiv gespeicherten Daten dann aktiviert und zur Rekonstruktion des Zustands des Netzwerks vor dem Absturz verwendet, um sicherzustellen, dass dabei keine Daten verloren gehen.
Logistisch koordiniert das Team über Zeitzonen und Disziplinen hinweg und nutzt cloudbasierte Tools für die Zusammenarbeit und Echtzeitüberwachung. Diese koordinierten Bemühungen erleichtern nicht nur die schnelle Entwicklung und Implementierung von Korrekturen, sondern stellen auch sicher, dass alle Teammitglieder über den Wiederherstellungsprozess und die nächsten Schritte informiert sind.
Dieser Vorfall diente als strenger Test der Crash-Management-Protokolle von Shardeum und verdeutlichte die Bedeutung agiler und innovativer Reaktionen auf unerwartete Herausforderungen. Dies unterstreicht das Engagement des Teams für die Aufrechterhaltung eines belastbaren und sicheren Netzwerks, das bereit ist, auftretende komplexe technische Hindernisse zu überwinden.
Innovationen für sichere und weltraumgebundene Landung
Zusammenfassend lässt sich sagen, dass die erfolgreiche Wiederherstellung des Shardeum-Shard-Netzwerks einen bedeutenden Wandel in der Netzwerktechnologie darstellt und einen Meilenstein mit weitreichenden Auswirkungen auf die Branche darstellt. Auch wenn Innovationen wie der Netzwerkmodus derzeit wenig bekannt sind, werden sie letztendlich neue Branchenstandards für web3 setzen.
Ich bin seit langem davon überzeugt, dass die Kerninnovationen von Shardeum höchstwahrscheinlich zukünftige technologische Entwicklungen beeinflussen und Innovationen und eine neue Generation der Ledger-Technologie anregen werden. Da ich die allererste Wiederherstellung des Shardeum-Netzwerks aus erster Hand miterlebt hatte, wusste ich, dass dies ein Katalysator für die Neubewertung von Industriestandards sein würde, was möglicherweise zur Einführung strengerer Protokolle und Methoden im Netzwerkdesign und in der Architektur führen würde.
Diese Veranstaltung zeigte nicht nur die technische Leistungsfähigkeit und Innovation des Shardeum-Teams, sondern markierte auch den Beginn einer Ära, in der dezentrale Netzwerke robuster, anpassungsfähiger und in der Lage sind, unvorhergesehene Herausforderungen bei der Notfallwiederherstellungsplanung zu bewältigen. Letztlich wird die Shardeum-Technologie eine neue Ära der Dezentralisierung einläuten.