Anwendungen, die bestimmte Chainlink-Preisfeeds verwenden, stehen vor einer kurzfristigen Wartungsfrist. Mehrere Einstellungen sind für den 30. September vorgesehen. Es geht um den technischen Betrieb und nicht um eine Kursprognose für die betroffenen Token. Software, die weiterhin einen nicht mehr unterstützten Feed liest, kann andere Risiken eingehen als eine Anwendung mit aktuellen Marktpreisen.
Chainlinks Änderungsprotokoll nennt betroffene Feeds auf verschiedenen Netzwerken, darunter EIGEN/USD auf Ethereum und MLN/USD auf Arbitrum. Entwickler müssen Netzwerk und Feed-Adresse mit den aktuellen Angaben abgleichen. Ein Tokensymbol allein reicht nicht aus, um festzustellen, ob eine bestimmte Anwendung betroffen ist.
Ein lesbarer Wert muss nicht aktuell sein
Eine Preisschnittstelle kann weiterhin einen Wert zurückgeben, obwohl der zugehörige Aktualisierungsprozess beendet wurde. Für finanzielle Entscheidungen ist das Alter dieses Werts ebenso wichtig wie sein Format. Eine erfolgreiche Abfrage beweist nicht, dass die Information für Liquidation, Sicherheitenberechnung oder Abwicklung geeignet ist.
Deshalb gehört der Umgang mit veralteten Daten in die Anwendungsgestaltung. Das Programm braucht eine festgelegte Reaktion, wenn ein Wert zu alt ist oder eine andere Gültigkeitsprüfung nicht besteht. Unverändertes Weiterarbeiten kann zu anderen Ergebnissen führen als das Anhalten einer sensiblen Funktion oder ein dokumentierter Ersatzweg.
Die richtige Antwort hängt vom Einsatzzweck ab. Ein reines Preisfenster und ein Kreditprotokoll tragen unterschiedliche Folgen, wenn Daten fehlen. Derselbe Ersatzmechanismus passt nicht überall, besonders wenn die alternative Quelle andere Aktualisierungszeiten oder eine andere Marktabdeckung besitzt.
Netzwerk und Adresse gehören zur Identität
Ähnlich benannte Preisfeeds können auf mehreren Blockchains existieren. Eine Einstellung auf einem Netzwerk beschreibt nicht zwangsläufig den Status auf einem anderen. Entwickler benötigen deshalb ein Verzeichnis der tatsächlich aufgerufenen Verträge, einschließlich indirekter Abhängigkeiten über weitere Komponenten.
Die offizielle Dokumentation erklärt die Produktfamilie und verweist auf unterstützte Feeds. Eine Wartungsprüfung sollte aktuelle Unterlagen verwenden und nicht ausschließlich eine alte Anleitung aus der ursprünglichen Einführung. Infrastrukturabhängigkeiten können sich nach dem Start einer Anwendung verändern.
Für Nutzer einer Anwendung liegt diese Arbeit normalerweise beim Betreiber. Eine unaufgeforderte Nachricht, die wegen eines Oracle-Updates die Verbindung einer Wallet oder die Offenlegung von Wiederherstellungsdaten verlangt, ist keine gewöhnliche Folge der Wartung. Die Änderung betrifft die Integration der Anwendung, nicht die Weitergabe privater Schlüssel.
Auch ein Ersatz muss geprüft werden
Der Wechsel zu einer anderen Quelle umfasst mehr als eine neue Adresse. Ein Ersatzfeed kann andere Dezimalstellen, Aktualisierungsbedingungen oder Asset-Konventionen verwenden. Eine fehlerhafte Interpretation kann gravierende Ergebnisse erzeugen, obwohl die neue Quelle selbst ordnungsgemäß funktioniert.
Tests sollten deshalb normale Werte, verzögerte Aktualisierungen und fehlende Daten abdecken. Außerdem sind sämtliche darauf beruhenden Berechnungen zu prüfen, etwa Grenzwerte und Verhältnisse. Eine kleine Codeänderung kann eine große finanzielle Wirkung haben, wenn sie Einheit oder Zeitpunkt eines Eingabewerts verändert.
TBJs Bericht über Solanas Finalitätsvorfall liefert eine breitere Parallele: Anwendungen beruhen auf Annahmen, deren Gültigkeit auch unter außergewöhnlichen Bedingungen überwacht werden muss. Zuverlässiger Betrieb setzt voraus, das Ende einer solchen Annahme zu erkennen und bewusst darauf zu reagieren.
Eine zweite Frist betrifft Aktienmarktdaten
Das Änderungsprotokoll nennt außerdem den 12. Oktober als Frist zur Entfernung produktiver Abhängigkeiten vom Feld lastTradedPrice in den betroffenen 24/5-Datenströmen für US-Aktien. Das Feld kann weiter vorhanden sein. Die angekündigte Änderung seiner Überwachung bedeutet jedoch, dass sein bloßes Auftauchen keine fortlaufende Produktionszusage belegt.
Das Beispiel verdeutlicht denselben Grundsatz wie die Feed-Einstellungen. Eine Schnittstelle kann ein Feld aus Kompatibilitätsgründen erhalten und gleichzeitig dessen Unterstützung verändern. Integratoren müssen die betriebliche Mitteilung lesen, statt aus einer weiterhin eintreffenden Antwort auf unveränderte Zusagen zu schließen.
Für eine geordnete Umstellung zählt zudem eine klare Zuordnung der Verantwortung. Jemand muss feststellen, welche Komponente den Wert verarbeitet und welche nachgelagerten Entscheidungen davon abhängen. Ohne diese Übersicht kann ein scheinbar erfolgreicher Austausch eine indirekte Abhängigkeit übersehen.
Die Hinweise belegen weder einen bereits eingetretenen Anwendungsausfall noch die Unsicherheit eines gelisteten Assets beim Handel. Sie benennen Abhängigkeiten, die Aufmerksamkeit erfordern. Nach Ablauf der Frist wird relevant sein, ob betroffene Betreiber ihre Migration abgeschlossen und den Umgang mit fehlenden oder veralteten Eingaben dokumentiert haben.
Die Wartungsfrist bietet damit einen klaren Anlass für einen vollständigen Abgleich. Entscheidend ist nicht nur, ob eine neue Adresse eingetragen wurde, sondern ob jede finanzielle Berechnung weiterhin die erwartete Bedeutung erhält. Ein erfolgreicher technischer Aufruf ist dafür notwendig, aber allein noch kein ausreichender Nachweis.
Für den breiteren Markt erinnert die Nachricht daran, dass dezentrale Finanzanwendungen gewartete Infrastruktur benötigen. Smart Contracts können Entscheidungen fortlaufend automatisieren, ihre Datenquellen besitzen trotzdem Lebenszyklen. Eine Einstellungsmitteilung macht daraus eine konkrete technische Aufgabe. Sie vorher zu lösen ist weniger störend, als die Änderung erst durch eine falsche finanzielle Berechnung zu entdecken.
