Was passiert mit Solana-Validatoren, die das Agave-4.4.1-Upgrade verpassen?

Anza gab Solana-Node-Betreibern bis zur Epoche 1079 Zeit, einen Patch zu installieren, der ändert, wie das Netzwerk die Kontodaten zählt, die eine Transaktion lädt. Ein Rechner, auf dem eine ältere Build-Version läuft, könnte online bleiben und dennoch mit der akzeptierten Chain nicht mehr Schritt halten, mit unterschiedlichen Folgen für Validatoren, die Staking-Belohnungen verdienen, und für Dienste, auf die Wallets für aktuelle Daten angewiesen sind.

Anza warnte Validatoren vor der Epoche 1079, dass Betreiber, die ältere Software ausführen, riskierten, zurückgelassen zu werden, wenn das Netzwerk eine neue Regel aktiviert. Die genannten kompatiblen Versionen waren Agave 4.4.1 und Firedancer v26.10.6.

Der Agave-Feature-Gate-Tracker identifiziert die relevante Änderung als eine Mindestgröße geladener Daten für loader-v3-ProgramData-Konten. Seine Versions-Untergrenzen-Tabelle trennt die von Testnetzwerken verwendeten Releases von den für das Mainnet geplanten. Das Lesen des Zeitplans erfordert, den Cluster, das Feature und die Epoche gemeinsam zu prüfen.

Die Frist betraf auch Nodes, die nicht abstimmen. Diese Maschinen können Wallets und Börsen mit Guthaben, Blockhashes und Bestätigungsdaten versorgen. Ein Problem bei einer von ihnen kann Nutzer erreichen, die nie SOL delegiert oder einen Validator ausgewählt haben.

Was die Änderung bewirkt

Ein Solana-Programm kann ein Konto verwenden, um seine ausführbaren Daten zu halten. Wenn eine Transaktion ein Programm laden muss, berücksichtigt das Netzwerk die mit diesem Vorgang verbundenen Daten. Ein auf ein Programm-Datenkonto angewendetes Minimum ändert, wie kompatible Software die relevante Transaktion unter der neuen Regel behandelt.

Der Zweck eines Feature-Gates besteht darin, zu koordinieren, wann die Teilnehmer beginnen, eine neue Regel zu verwenden. Betreiber können ein Release im Voraus installieren, während die eigentliche Regeländerung zu einem vereinbarten Zeitpunkt wirksam wird. Eine Version kann daher ein Feature unterstützen, bevor dieses Feature im Mainnet aktiv ist.

Sobald das Gate aktiviert ist, kann ein älteres Release in Bezug auf eine Transaktion oder den durch einen Block erzeugten Zustand von der aktualisierten Software abweichen. Ein Validator kann dann aufhören, der vom Rest des Netzwerks anerkannten Chain zu folgen, obwohl der Server selbst online bleibt. Das ist die praktische Bedeutung von Anzas Warnung vor dem Forked-Off-Werden.

Warum das hinter den Nodes stehende Stake zählt

Hundert kleine Validatoren und eine Handvoll großer Betreiber müssen nicht vergleichbare Mengen an Voting-Stake repräsentieren. Für den Betrieb des Netzwerks ist die relevante Frage, wie viel Stake den kompatiblen Regeln folgt. Der Tracker besagt, dass Änderungen der Mainnet-Untergrenze bei Minor-Versionen normalerweise einem Stake-Adoptionsschwellenwert und einer Wartezeit folgen. Diese allgemeine Regel sollte von der spezifischen Warnung, die vor der Epoche 1079 ausgegeben wurde, getrennt gehalten werden.

Eine Adoptionsprüfung sollte Versionsinformationen mit aktivem Stake kombinieren und diese Zahlen dann mit der Voting-Teilnahme nach der Grenze vergleichen. Ein Node, der das richtige Release meldet, kann sich noch im Aufholprozess befinden oder einen separaten Fehler aufweisen. Umgekehrt kann ein stabiler aggregierter Wert Probleme bei einem kleineren Betreiber verschleiern, wenn der Großteil des Stakes online bleibt und normal abstimmt.

Dieser Unterschied ist für Delegierende wichtig. Ihre Erfahrung hängt von dem Validator ab, dem ihr Stake zugewiesen wurde, und nicht davon, ob eine Mehrheit der Maschinen das Release installiert hat. Wenn ein Validator aufhört, effektiv abzustimmen, kann die verpasste Teilnahme die diesem Stake zurechenbaren Belohnungen verringern. Der relevante Beleg wären Vote-Credits und Belohnungsaufzeichnungen für die betroffenen Epochen.

Was Nutzer und Börsen bemerken würden

Ein Nutzer, der SOL sendet, legt Wert darauf, ob die Überweisung akzeptiert wird und das beabsichtigte Bestätigungsniveau erreicht. Das lässt sich anhand der Transaktions- und Netzwerkdaten überprüfen. Die Behauptung, dass mehrere Betreiber ein Update verpasst haben, belegt für sich genommen weder langsamere Bestätigungen noch einen Stillstand oder einen weitreichenden Ausfall.

Eine Börse kann auch Einzahlungen oder Auszahlungen pausieren, während sie ein Upgrade überwacht, selbst wenn Transfers onchain weiterlaufen. Die Kundenguthaben hängen von ihrer eigenen Infrastruktur und ihren Gutschriftrichtlinien ab. Eine Transaktion, die onchain erscheint, kann daher im Börsenkonto eines Kunden ausstehend bleiben, bis dieser Handelsplatz die normale Verarbeitung wieder aufnimmt.

Der nützliche Vergleich nach dem Upgrade würde drei Dinge getrennt prüfen. Erstens: Wurden weiterhin Blöcke produziert und bestätigt? Zweitens: Hat sich die Menge des effektiv abstimmenden Stakes geändert? Drittens: Hat eine namentlich genannte Börse Transfers rund um die Grenze pausiert oder wieder aufgenommen? Jede Antwort erfordert einen anderen Nachweis.

Warum die Upgrade-Frist auch für die Infrastruktur galt

Die Agave-Release-Notes von Anza bezeichnen die Änderung der ProgramData-Buchführung als Backport. Das Firedancer-Release enthält Unterstützung für dieselbe Funktion. Wenn zwei Clients dieselbe Transaktion nach der Aktivierung verarbeiten, müssen sie sich darüber einig sein, wie viele Kontodaten sie lädt. Die gemeinsame Regel ist an der Grenze entscheidend.

Ein nicht gestakter RPC-Knoten kann eine Anwendung bedienen, ohne Stake zu den Abstimmungen beizutragen. Dadurch kann ein Wallet-Nutzer leicht auf ein lokales Problem stoßen, selbst wenn die abstimmenden Validatoren weiterhin Blöcke produzieren. Eine Anwendung, die von einem hinterherhinkenden Endpunkt liest, kann einen veralteten Zustand anzeigen oder einen Fehler zurückgeben. Der Vergleich ihrer Antwort mit derselben Anfrage über einen anderen Endpunkt hilft festzustellen, wo die Störung aufgetreten ist.

Solanas Alpenglow-Migration im Oktober bietet Kontext dafür, wie Betreiber sich auf eine koordinierte Änderung vorbereiten. Diese Migration betraf das Konsensprotokoll. Der Patch vom November betraf das Laden von Konten. Beide geben Betreibern eine Version zum Überprüfen, aber die Auswirkungen müssen anhand der spezifischen Regel bewertet werden, die sich geändert hat.

Was die Frist von einem Veröffentlichungsdatum unterschied

Anza veröffentlichte Agave 4.4.1 am 5. November. Die anschließende Warnung an die Betreiber besagte, dass die Änderung für Epoche 1079 geplant war, deren Beginn auf etwa 13:30 UTC am 6. November geschätzt wurde. Die Version bezeichnete die Software, die die Betreiber benötigten, während die Epoche angab, wann das Netzwerk planmäßig beginnen sollte, die Regel anzuwenden.

Eine Epochengrenze hängt vom Fortschritt der Chain ab. Die Zeitangabe in der Warnung gab den Betreibern eine praktische Schätzung, aber der Übergang der Chain in die neue Epoche war das entscheidende Ereignis. Betreiber konnten eine spätere lokale Uhrzeit oder ein routinemäßiges Wartungsfenster nicht als Verlängerung des Zeitplans betrachten.

Ein Release kann Code enthalten, der noch nicht ändert, wie das Netzwerk Transaktionen verarbeitet. Betreiber installieren zuerst die Software, dann aktiviert das Netzwerk die Funktion zum geplanten Zeitpunkt. Diese Abfolge ermöglicht es Betreibern, sich vorzubereiten, ohne dass Knoten sofort unterschiedliche Regeln auf denselben Block anwenden.

Das Zeitfenster war kurz, selbst für Betreiber, die bereits auf Agave 4.4.0 umgestiegen waren. Die Patch-Nummer änderte sich um eins, aber das frühere Release enthielt nicht die für die neue Regel erforderliche Unterstützung. Eine kürzliche Installation war daher kein Ersatz für die Überprüfung des genauen Builds.

Das Firedancer-Release 26.10.6 unterstützte dieselbe Funktion. Betreiber konnten unterschiedliche Client-Implementierungen verwenden, aber beide mussten dieselben Kontodaten zählen, wenn sie eine Transaktion unter den aktiven Regeln ausführten.

Die Unterscheidung zwischen Software und Aktivierung war bereits in der crypto.news-Berichterstattung über Alpenglows Testnet-Rollout aufgetaucht. Alpenglow änderte den Konsens, während der November-Patch die Transaktionsverarbeitung betraf. In beiden Fällen war ein verfügbarer Build ein separater Meilenstein davon, dass das Netzwerk sein Verhalten verlangte.

Wo ProgramData in die Transaktion eintritt

Eine Transaktion listet Konten auf, die ihre Anweisungen benötigen. Ein Validator lädt die mit diesen Konten verbundenen Daten, um die Anweisungen auszuführen. Das Netzwerk begrenzt, wie viele Kontodaten eine Transaktion laden kann, und gibt Validatoren damit eine Obergrenze für eine Kategorie von Arbeit, die sie vor oder während der Ausführung leisten.

Solanas upgradebarer Loader verwendet ein Programm-Konto und ein separates ProgramData-Konto. Letzteres speichert die ausführbaren Programmdaten und zugehörige Informationen für den Loader. Ein Benutzer ruft das Programm auf, ohne die Größe dieser ausführbaren Daten manuell zu berücksichtigen. Die Laufzeitumgebung des Validators übernimmt diesen Teil.

Der Patch legt einen Mindestwert für den Betrag fest, der einem Loader-v3-ProgramData-Konto bei dessen Laden zugerechnet wird. Wenn die alte Abrechnung weniger als den Mindestwert zurechnete, zählt die neue Regel mindestens das Minimum gegen das geladene Datenlimit der Transaktion. Eine Transaktion, die deutlich unter dem Limit liegt, kann nach der Änderung dasselbe Ergebnis erzeugen.

Der Unterschied ist an der Grenze von Bedeutung. Eine Transaktion, die mehrere Anweisungen kombiniert oder mehrere Programme verwendet, kann bereits erhebliche Kontodaten laden. Wenn das neue Minimum den kombinierten Betrag über das Limit hebt, können die alte und die neue Regel unterschiedliche Ergebnisse erzeugen, selbst bei denselben Anweisungen und demselben Unterzeichner.

Das geladene Datenlimit ist vom Compute-Budget zu unterscheiden. Compute misst die Ausführungsarbeit. Eine Transaktion kann über ausreichend Compute verfügen, um die Anweisungen auszuführen, und dennoch ein Limit verletzen, das regelt, welche Konten sie laden kann. Eine Erhöhung des Compute-Kontingents allein ändert nicht den Betrag, der gegen das geladene Datenlimit gezählt wird.

Die Regel lässt auch die bereitgestellten Anweisungen einer Anwendung an Ort und Stelle. Das Programm kann an derselben Adresse stehen und denselben Code haben, während der Validator sein ProgramData-Konto anders berechnet. Anwendungsteams haben einen Grund, Transaktionen nahe dem Limit erneut zu prüfen, selbst wenn sie selbst keine Bereitstellung vorgenommen haben.

Wie zwei Knoten über denselben Block uneinig sein können

Validatoren führen Transaktionen aus, um den von einem Block erzeugten Zustand zu prüfen. Wenn zwei Knoten vom selben Zustand ausgehen und unterschiedliche Regeln auf eine dieser Transaktionen anwenden, können sie zu unterschiedlichen Ergebnissen gelangen. Sie können nicht beide denselben resultierenden Zustand als gültig behandeln, es sei denn, der Unterschied wird aufgelöst.

Das erklärt Anzas Warnung, dass ältere Knoten aus dem Tritt geraten. Ein alter Knoten kann online bleiben und weiterhin Anfragen beantworten, während er die von kompatiblen Validatoren akzeptierte Kette nicht verfolgt. Dass sein Prozess läuft, ist ein schwächerer Test als die Frage, ob er aktuell ist und mit dem Cluster übereinstimmt.

Ein Betreiber kann den vom Knoten gemeldeten Slot mit einer unabhängigen Referenz vergleichen. Ein abstimmender Validator muss außerdem prüfen, dass seine Stimmen auf der akzeptierten Kette gezählt werden. Fehlerprotokolle können ein Problem beim Wiederabspielen von Blöcken identifizieren, das bei einer Uptime-Prüfung unsichtbar wäre.

Die Warnung beschrieb die Folge der Inkompatibilität. Eine Bewertung nach der Frist muss noch zeigen, welche Betreiber veraltete Builds ausführten und was mit ihren Knoten geschah. Ein Versions-Snapshot, der nach der Wiederherstellung eines Betreibers erfasst wurde, könnte einen kurzen Zeitraum verfehlen, in dem dieser Validator aus dem Tritt war.

Das Datum der Aktivierung und der Zeitpunkt, zu dem ein Beobachter ein Problem bemerkt, können ebenfalls differieren. Eine enge Regel betrifft nur Transaktionen, die sie ausüben. Ein Zeitraum ohne sichtbare Abweichung unmittelbar nach der Grenze würde nicht zeigen, ob ein Knoten eine Transaktion nahe dem betroffenen Limit verarbeiten konnte.

Warum eine Validator-Anzahl nur einen Teil der Geschichte erzählt

Die Bedeutung eines abstimmenden Validators hängt teilweise davon ab, wie viel Stake er repräsentiert. Eine Handvoll großer Betreiber kann mehr Stimmgewicht repräsentieren als viele kleinere. Eine Zählung der betroffenen Maschinen beantwortet daher eine andere Frage als der Prozentsatz des aktiven Stakes, der weiterhin teilnahm.

Nicht gestakte Knoten haben eine separate Rolle. Sie können Anwendungen, Börsen und Wallets mit Daten versorgen oder signierte Transaktionen weiterleiten. Ein Ausfall bei einem beliebten Dienst kann viele Benutzer betreffen, obwohl der Dienst keinen Stake zum Konsens beiträgt.

Die relevanten Maße können sich unabhängig voneinander bewegen. Die Blockproduktion kann weiterlaufen, während ein bestimmter RPC-Anbieter veraltete Daten liefert. Ein Validator kann Stimmen verpassen, während seine öffentlich zugängliche Website verfügbar bleibt. Eine Börse kann Solana-Einzahlungen pausieren, während die Kette weiterhin Überweisungen bestätigt.

Eine frühere Berichterstattung über Solanas Alpenglow-Frist beschrieb eine Übergabe, die eine koordinierte Vorbereitung durch Validatoren und Anwendungen erforderte. Das Ziel dort war eine schnellere Finalität. Das ProgramData-Gate hat eine engere technische Wirkung, aber Betreiber müssen die Bereitschaft dennoch anhand ihrer eigenen Position im Netzwerk beurteilen.

Was Delegatoren aus Abstimmungs- und Belohnungsaufzeichnungen ableiten können

Delegatoren haben eine wirtschaftliche Frage, selbst wenn das Netzwerk verfügbar bleibt. Sie möchten wissen, ob der Validator, der in ihrem Namen Belohnungen verdient, weiterhin teilgenommen hat. Ein verpasster Patch verschiebt delegierte SOL nicht von selbst aus dem Stake-Konto, aber eine Unterbrechung der Abstimmung kann die in dem betreffenden Zeitraum verdienten Belohnungen verringern.

Die erste Anlaufstelle ist das Vote-Konto des Validators. Ein Vergleich der Vote-Credits über die Epochen um die Grenze herum kann feststellen, ob sich seine Teilnahme verändert hat. Belohnungsaufzeichnungen bieten eine separate Überprüfung der Auswirkung für bestimmte Stake-Konten.

Eine niedrigere Belohnung allein identifiziert das Upgrade nicht als Ursache. Provision, die frühere Leistung des Validators und der Status des Stake-Kontos können alle den aufgezeichneten Betrag beeinflussen. Der Nachweis, dass die Abstimmungen an der Grenze aufhörten und nach einer Client-Änderung wieder aufgenommen wurden, wäre eine stärkere Erklärung als eine einzelne niedrigere Belohnung.

Ein Liquid-Staking-Token fügt eine weitere Ebene hinzu. Ein Pool kann seinen Stake über mehrere Validatoren verteilen. Ein Problem bei einem Betreiber kann je nach seinem Anteil an der Delegation und der Buchführung des Pools nur einen Teil der Veränderung der Pool-Belohnungen ausmachen.

Exchange-Staking fügt eine Dienstleistungsbeziehung hinzu. Die Exchange kann eigene Validatoren betreiben oder einen anderen Anbieter nutzen und dann Kunden gemäß ihren Bedingungen gutschreiben. Ein Nutzer bräuchte die Aufzeichnungen der Exchange, um eine Onchain-Veränderung bei den Abstimmungen mit der einem einzelnen Konto gutgeschriebenen Belohnung zu verbinden.

Was ein veralteter RPC-Endpunkt mit einer Wallet anrichten kann

Viele Wallets beziehen Guthaben, Blockhashes und Transaktionsergebnisse über einen RPC-Endpunkt. Ein Knoten, der zurückfällt, kann ein früheres Guthaben melden oder eine aktuelle Transaktion nicht zurückgeben. Nutzer können auf diese Symptome stoßen, selbst wenn andere Knoten das Netzwerk normal verarbeiten.

Ein Blockhash kann die Transaktion beeinflussen, bevor das Netzwerk sie ausführt. Eine Wallet, die einen veralteten Blockhash erhält, kann eine Transaktion konstruieren, die nicht mehr gültig ist, wenn sie einen gesunden Knoten erreicht. Das Symptom ist eine fehlgeschlagene Übermittlung, aber der Grund können veraltete Informationen sein und nicht eine Änderung des Guthabens oder der Anweisungen.

Die Simulation hängt von derselben Beziehung ab. Ein Knoten, der alte Regeln ausführt, kann melden, dass eine Transaktion in das geladene Datenlimit passt, obwohl die Knoten, die die neue Regel durchsetzen, zu einem anderen Ergebnis kommen. Eine Simulation auf einem kompatiblen Knoten kann sich dennoch von der endgültigen Ausführung unterscheiden, wenn sich der Zustand zwischen der Simulation und der Aufnahme ändert.

Anwendungen mit mehreren Knoten hinter einem einzigen Endpunkt stehen vor einer weiteren Möglichkeit. Anfragen können erfolgreich sein oder fehlschlagen, je nachdem, welche Maschine sie empfängt. Ein Anbieter muss prüfen, ob der gesamte Pool aktuell ist, bevor er ein intermittierendes Problem der Chain zuschreibt.

Ein Vergleich zwischen unabhängigen Endpunkten hilft, diese Probleme zu trennen. Wenn mehrere aktuelle Endpunkte übereinstimmen und ein Dienst abweicht, kann die Diskrepanz lokal zu diesem Dienst gehören. Wenn unabhängige Beobachter ebenfalls eine Veränderung bei der Blockproduktion oder den Bestätigungen melden, gibt es stärkere Hinweise auf ein Netzwerkproblem.

Der Konsensübergang im Oktober brachte eigene Infrastrukturänderungen mit sich. Crypto.news berichtete, dass Alpenglow die bisherigen Onchain-Abstimmungstransaktionen entfernte. Anwendungsteams mussten die Veränderung dessen, was sie beobachteten, davon unterscheiden, ob Validatoren dem neuen System folgen konnten. Die Kontoladeregel vom November macht die Antwort erneut vom Beobachter abhängig.

Warum die Exchange-Gutschrift hinter der Chain zurückbleiben kann

Eine Exchange kann eine Einzahlung erst gutschreiben, nachdem ihre Systeme die Übertragung erkannt und ihre Bestätigungsrichtlinie angewendet haben. Eine erfolgreiche Onchain-Transaktion bestimmt daher nicht, wann sich das interne Exchange-Guthaben eines Kunden ändert.

Eine Handelsplattform kann Einzahlungen oder Auszahlungen pausieren, während sie ihre Infrastruktur aktualisiert. Sie kann auch weiterhin Überweisungen onchain empfangen, während ihre Einzahlungswarteschlange auf die Bestätigung von einem gesunden Node wartet. Ein Hinweis der Handelsplattform und ein Block-Explorer können beide korrekt sein, selbst wenn der eine eine Dienstunterbrechung und der andere eine erfolgreiche Überweisung anzeigt.

Bei Auszahlungen kann es zu einer Verzögerung kommen, bevor die Börse die Transaktion signiert oder überträgt. Das Fehlen eines Onchain-Eintrags während dieser Zeit sagt wenig darüber aus, ob das Netzwerk die Transaktion nach der Einreichung akzeptieren würde. Der Verarbeitungsstatus der Handelsplattform betrifft diesen Teil der Zeitachse.

Ein Bericht, dass mehrere Börsen den Betrieb pausiert hätten, müsste dennoch angeben, welche Dienste betroffen waren und welchen Grund jede einzelne nannte. Ein routinemäßiger Wartungshinweis oder eine durch ein anderes Problem verursachte Warteschlange kann in dasselbe Zeitfenster wie ein Upgrade fallen. Die zeitliche Koinzidenz ist ein Grund, die Aufzeichnungen zu vergleichen, kein Maß für die Netzwerkteilnahme.

Was zeigen würde, ob Betreiber den Patch verpasst haben

Der Anza-Feature-Gate-Tracker trennt die minimale Release-Untergrenze von einzelnen Aktivierungen. Frühere Berichte von crypto.news über den Alpenglow-Rollout und die Mainnet-Untergrenze beschrieben dieselbe Unterscheidung. Ein Build kann die Untergrenze zu einem Zeitpunkt erfüllen und dennoch eine für eine spätere Epoche geplante Änderung nicht enthalten.

Die nützlichste Aufzeichnung nach der Aktivierung würde das aktive Feature, die Softwareverteilung und die Betreiberteilnahme über dasselbe Zeitfenster vergleichen. Die Feature-Aufzeichnung gibt an, wann die Regel begann zu gelten. Die Software-Aufzeichnung gibt an, welche Builds im Einsatz waren. Stimmen und Blöcke zeigen, ob sich das Netzwerk und einzelne Betreiber anders verhielten.

Ausgelassene Slots sind eine mögliche Beobachtung. Sie können auch aus Gründen zunehmen, die nichts mit dem Patch zu tun haben, einschließlich der gewöhnlichen Leistung der Validatoren, die zur Führung zugewiesen sind. Der Vergleich mehrerer Zeitfenster und die Zuordnung der Auslassungen zu ihren Leadern gibt der Beobachtung Kontext.

Säumiges Stake bietet eine andere Sichtweise. Der Betrag kann sich bewegen, wenn ein großer Validator die Teilnahme einstellt, selbst wenn sich die Gesamtzahl der säumigen Nodes kaum ändert. Der Vergleich muss Betreiber berücksichtigen, die bereits vor dem Upgrade säumig waren.

RPC- und Börseneffekte müssen separat dokumentiert werden. Diese Anbieter können große Nutzerzahlen bedienen, ohne im Stake-Vergleich zu erscheinen. Ihre Hinweise, Dienstmetriken und Aufzeichnungen darüber, wann Nodes zu aktuellen Slots zurückkehrten, würden Störungen beschreiben, die die Abstimmungsdaten nicht erfassen können.

Warum ein gestaffelter Rollout dennoch einen Aktivierungstest braucht

Ein stabiles Client-Release kann schrittweise bereitgestellt werden, bevor ein neues Feature aktiv ist. Das ermöglicht es Betreibern zu sehen, ob die Software korrekt startet, aufholt und Transaktionen unter den aktuellen Regeln verarbeitet. Es hilft auch, Bereitstellungsprobleme aufzudecken, bevor mehr Nodes sie verwenden.

Ein erfolgreicher Rollout vor der Aktivierung kann nicht jede Konsequenz des aktiven Features erproben. Eine Transaktion nahe dem Grenzwert für geladene Kontodaten muss unter beiden Regelsätzen getestet werden, um genau zu zeigen, wo sich das Ergebnis ändert. Das ist ein anderer Test als zu beobachten, ob die Binärdatei online bleibt.

Crypto.news berichtete zuvor, dass Alpenglow einen anderen Ansatz für Finalität anstrebte. Zu seinen Erfolgskriterien gehörte, was mit der Bestätigungsgeschwindigkeit geschah. Der ProgramData-Patch lässt sich besser daran beurteilen, ob Clients bei Transaktionen übereinstimmen, die auf das neue Limit stoßen, und ob die Infrastruktur nach dem Einschalten des Gates verfügbar bleibt.

Ein Rollback ändert bei der Aktivierung ebenfalls seine Bedeutung. Vor der Grenze kann ein älteres unterstütztes Release möglicherweise noch die bereits geltenden Regeln verarbeiten. Danach kann die Rückkehr zu einem Build, dem das Feature fehlt, genau die Inkompatibilität zurückbringen, die der Betreiber zu beheben versuchte. Ein Fallback muss die Unterstützung für das aktive Gate beibehalten.

Ein Betreiber mit Reservekapazität kann einen gepatchten Node hochfahren und ihn validieren, bevor er Traffic zuweist. Ein kleinerer Betreiber muss möglicherweise seinen einzigen Node neu starten und warten, bis er aufgeholt hat. Die Frist ist gemeinsam, aber die Zeit, die Nutzer mit Warten verbringen, kann von der Redundanz des Anbieters abhängen.

Warum der Preis von SOL die Wirkung des Upgrades nicht messen kann

SOL kann in denselben Stunden fallen oder steigen, in denen Betreiber einen Patch installieren. Es wird gegen viele derselben Währungen und Kapitalpools gehandelt wie andere Krypto-Assets. Zinssätze, Bewegungen bei Bitcoin und Veränderungen der Hebelwirkung können den Preis im selben Zeitfenster beeinflussen.

Ein technisches Problem kann für den Handel relevant sein, wenn es Überweisungen unterbricht oder eine Anwendung nicht verfügbar macht. Belege für diese Erklärung wären Hinweise von Handelsplätzen, Änderungen bei Ein- oder Auszahlungen oder Onchain-Ausführungsdaten, die mit den betreffenden Konten verknüpft sind. Ein Token-Preis allein identifiziert diesen Kanal nicht.

Ein einzelner Transaktionsfehler unterscheidet sich auch vom Verlust der Kontrolle über ein Konto. Eine Wallet kann eine Transaktion mit veralteten Informationen erstellt oder sie über einen veralteten Node übermittelt haben. Der Benutzer kann das Konto weiterhin kontrollieren, während die Anwendung Schwierigkeiten hat, das aktuelle Netzwerk zu erreichen.

Der direkteste Test nach der Frist liegt daher auf der Ebene des Dienstes. Ein Voting-Node sollte aktuell sein und Stimmen aufzeichnen. Ein RPC-Dienst sollte Anfragen von der akzeptierten Chain beantworten. Eine Börse sollte nachweisen können, ob und wann sie Überweisungen verarbeitet hat, die rund um den Wechsel eingereicht wurden.

Diese Belege können eine Bewertung stützen, selbst wenn sich der Preis aus unabhängigen Gründen bewegt. Sie geben Delegatoren auch eine Möglichkeit, die Leistung ihres eigenen Validators zu bewerten, ohne eine netzwerkweite Versionsanforderung als Aussage über die Ergebnisse jedes Betreibers zu behandeln.

Was passiert, wenn ein Betreiber wieder online kommt

Die Installation der gepatchten Software ist ein Schritt bei der Wiederherstellung eines Nodes. Der Betreiber muss dann sehen, ob der Prozess zur akzeptierten Chain aufschließt und ihr unter den aktuellen Regeln folgt. Ein Server kann erfolgreich neu starten, während er noch Blöcke wiedergibt oder Daten zurückgibt, die hinter der Spitze zurückliegen.

Ein Voting-Node muss auch zeigen, dass seine Beteiligung wieder aufgenommen wurde. Sein Betreiber kann die aktuellen Stimmen mit dem Zeitpunkt vergleichen, zu dem sich der Node erholt hat. Ein Delegator, der später Belohnungsdaten liest, kann dann den Wiederherstellungspunkt vom Zeitpunkt der Patch-Installation unterscheiden.

Ein Dienstanbieter kann einen gepatchten Node aus der Rotation nehmen, bis er aufgeholt und Prüfungen bestanden hat. Der Betreiber kann den Slot, das Ergebnis einer kürzlichen Transaktion und das Ergebnis einer Simulation mit einer separaten Referenz vergleichen. Ein Anbieter, der den Node vor diesen Prüfungen wieder in den Verkehr bringt, kann ein Software-Upgrade abgeschlossen erscheinen lassen, während Kunden weiterhin auf alte Daten stoßen.

Der Zeitablauf ist wichtig, wenn die Auswirkungen bewertet werden. Ein Node, der abwich und innerhalb derselben Epoche zurückkehrte, kann in einem späteren Verzeichnis gesund erscheinen. Seine verpasste Beteiligung kann für den Betreiber oder Delegatoren dennoch von Bedeutung sein. Eine öffentliche Incident-Zeitleiste müsste genügend Details enthalten, um zu zeigen, wann der Dienst eingestellt und wann die normale Aktivität wieder aufgenommen wurde.

Anwendungsteams können auch Transaktionen untersuchen, die nur über ein bestimmtes Backend fehlgeschlagen sind. Wenn das erneute Einreichen über einen aktuellen Node das Problem ohne Änderung der Anweisungen löst, wird der frühere Endpunkt zu einer wahrscheinlichen Fehlerquelle. Wenn dieselbe Transaktion über aktuelle Nodes in der Nähe des Kontodatenlimits konsistent fehlschlägt, muss die Transaktion selbst möglicherweise neu erstellt werden.

Eine solche Neuerstellung kann das Reduzieren der von der Transaktion geladenen Daten oder das Trennen von Anweisungen umfassen, wo die Anwendung mehrere Transaktionen tolerieren kann. Das Aufteilen einer Transaktion kann ihre Garantien ändern, da Anweisungen, die gemeinsam erfolgreich sein oder fehlschlagen sollten, dies möglicherweise nicht mehr tun. Die Änderung gehört daher zum eigenen Design der Anwendung, zusammen mit ihren Anforderungen an das Laden von Konten.

Die Konsequenzen für einen Benutzer hängen davon ab, wo die Inkompatibilität aufgetreten ist. Ein Betreiber kann die Beteiligung verpassen, ein RPC kann veraltete Informationen zurückgeben und eine Anwendung kann eine Transaktion erstellen, die nicht mehr passt. Die ersten beiden können durch die Wiederherstellung kompatibler Infrastruktur behoben werden, während die dritte von der Transaktion und der aktiven Regel abhängt.

Eine Prüfung der Wiederherstellung von Solana sollte diese Beobachtungen getrennt halten. Sie sollte Abstimmungsaufzeichnungen für Betreiber, Dienstaufzeichnungen für Anbieter und Ausführungsergebnisse für betroffene Anwendungen vergleichen. Dadurch wird es möglich, eine eng begrenzte Auswirkung zu identifizieren, selbst wenn das Netzwerk durchgehend Blöcke produziert hat.

Die November-Frist gab Betreibern ein benanntes Release und eine Epochengrenze. Die dauerhafte Aufzeichnung ihrer Auswirkungen wird sich daraus ergeben, was Nodes rund um diese Grenze taten und welchen Dienst sie danach bereitstellen konnten.

Worauf zu achten ist

• Kompatible Releases: Anzas Zeitplan und die Release Notes können den Mainnet-Standard und seine Entsprechungen über verschiedene Clients hinweg festlegen.
• Beteiligung an Abstimmungen: Aktives Stake und Stimmguthaben können zeigen, ob sich die Beteiligung an Abstimmungen rund um die Grenze verändert hat.
• Netzwerkbestätigungen: Block- und Bestätigungsaufzeichnungen können zeigen, ob das Netzwerk die Verarbeitung von Transaktionen rund um die Änderung fortgesetzt hat.
• Börsenbetrieb: Handelsplatzhinweise können feststellen, ob eine Börse ihre eigenen Solana-Einzahlungen oder -Auszahlungen ausgesetzt hat.

FAQs