Ändere „panic“ zu strukturierten Fehlern: So wird der gesamte Knoten geschützt, nicht nur eine einzelne fehlerhafte Transaktion
Ich bewerte, wie reif eine kryptografische Codebasis ist, besonders daran, wie sie mit fehlerhaften Eingaben umgeht. Korrekt mit normalen Daten umzugehen ist nur der erste Schritt; bei abgeschnittenen, verstümmelten oder absichtlich konstruierten Daten entscheidet sich, ob ein klassifizierbarer Fehler zurückgegeben wird oder ob ein „panic“ den Prozess zum Auseinanderfallen bringt. Davon hängt ab, ob sich die Wirkung auf eine einzige Anfrage beschränkt oder auf den gesamten Dienst ausweitet. Dusk hat diese Woche für Phoenix Core die Fehler einzeln in die Dusk-Bytes-Ergebnis-Mapping-Logik ergänzt und die erreichbaren „unwind“-Pfade durch strukturierte Fehler ersetzt. Das ist ein typisches Beispiel für „Fehlschlag muss beherrschbar sein“.
Der Wert strukturierter Fehler geht jedoch nicht nur in Richtung schönerer Logs. Wenn ein Knoten eine ungültige Datenmenge erhält, kann er je nach Fehlerart ablehnen, zählen, drosseln oder die Quelle markieren; und das Wallet kann dem Nutzer mitteilen, ob die Länge falsch ist, ob die Entschlüsselung fehlgeschlagen ist oder ob das Format nicht unterstützt wird. Wenn alle Ausnahmen in denselben Absturz münden, kann das Betriebssystem nur den Prozessabbruch sehen. Es ist dann weder möglich, bösartige Eingaben von normaler Beschädigung zu unterscheiden, noch wird verhindert, dass das gleiche Problem nach automatischem Neustart erneut ausgelöst wird.
Noch wichtiger ist, dass das Fehler-Mapping vollständig sein muss. Wenn die zugrunde liegende Bibliothek einen neuen Fehlerzweig hinzufügt und die obere Schicht ihn schlampig mit einem Wildcard-Case abfängt, kann es passieren, dass ein eigentlich abzulehnender Fall geschluckt wird oder dass interne Details nach außen dringen. Robuster ist es, jeden erreichbaren Fehler in Phoenix Core explizit aufzuzählen, das zugehörige Dusk-Bytes-Ergebnis zu definieren und per Tests sicherzustellen, dass keine Pfade die Grenze zu „panic“ überschreiten. Bei nicht vertrauenswürdigen Eingaben sollte man zudem zunächst Länge und Format prüfen und erst danach die teure Entschlüsselung oder Kurvenberechnung ausführen.
Natürlich heißt „nicht abstürzen“ nicht, dass die Eingaben gültig sind, und es bedeutet auch nicht, dass die alten Phoenix-Transaktionen nachträglich wieder akzeptiert werden. Nach Boreas stoppt das Mainnet bereits innerhalb der festgelegten Grenzen die Annahme neuer Phoenix-Transaktionen, aber die Knoten müssen weiterhin Historie dekodieren und ausführen können, um alte Blöcke zu synchronisieren und erneut abzuspielen.
Darum halte ich diese Fehlerbehandlungs-Verstärkung bei @Dusk für besonders wichtig: Sie schützt nicht nur einzelne Requests, sondern die tatsächliche Störungsreichweite im Netzwerk. Finanzielle Infrastruktur kann nicht garantieren, nie auf kaputte Daten zu stoßen—aber sie kann sicherstellen, dass kaputte Daten nur zu einer klaren Ablehnung führen und nicht unbeteiligte Nutzer gleich mit in den Ausfall hineinziehen.
@Dusk $DUSK #dusk
Ich bewerte, wie reif eine kryptografische Codebasis ist, besonders daran, wie sie mit fehlerhaften Eingaben umgeht. Korrekt mit normalen Daten umzugehen ist nur der erste Schritt; bei abgeschnittenen, verstümmelten oder absichtlich konstruierten Daten entscheidet sich, ob ein klassifizierbarer Fehler zurückgegeben wird oder ob ein „panic“ den Prozess zum Auseinanderfallen bringt. Davon hängt ab, ob sich die Wirkung auf eine einzige Anfrage beschränkt oder auf den gesamten Dienst ausweitet. Dusk hat diese Woche für Phoenix Core die Fehler einzeln in die Dusk-Bytes-Ergebnis-Mapping-Logik ergänzt und die erreichbaren „unwind“-Pfade durch strukturierte Fehler ersetzt. Das ist ein typisches Beispiel für „Fehlschlag muss beherrschbar sein“.
Der Wert strukturierter Fehler geht jedoch nicht nur in Richtung schönerer Logs. Wenn ein Knoten eine ungültige Datenmenge erhält, kann er je nach Fehlerart ablehnen, zählen, drosseln oder die Quelle markieren; und das Wallet kann dem Nutzer mitteilen, ob die Länge falsch ist, ob die Entschlüsselung fehlgeschlagen ist oder ob das Format nicht unterstützt wird. Wenn alle Ausnahmen in denselben Absturz münden, kann das Betriebssystem nur den Prozessabbruch sehen. Es ist dann weder möglich, bösartige Eingaben von normaler Beschädigung zu unterscheiden, noch wird verhindert, dass das gleiche Problem nach automatischem Neustart erneut ausgelöst wird.
Noch wichtiger ist, dass das Fehler-Mapping vollständig sein muss. Wenn die zugrunde liegende Bibliothek einen neuen Fehlerzweig hinzufügt und die obere Schicht ihn schlampig mit einem Wildcard-Case abfängt, kann es passieren, dass ein eigentlich abzulehnender Fall geschluckt wird oder dass interne Details nach außen dringen. Robuster ist es, jeden erreichbaren Fehler in Phoenix Core explizit aufzuzählen, das zugehörige Dusk-Bytes-Ergebnis zu definieren und per Tests sicherzustellen, dass keine Pfade die Grenze zu „panic“ überschreiten. Bei nicht vertrauenswürdigen Eingaben sollte man zudem zunächst Länge und Format prüfen und erst danach die teure Entschlüsselung oder Kurvenberechnung ausführen.
Natürlich heißt „nicht abstürzen“ nicht, dass die Eingaben gültig sind, und es bedeutet auch nicht, dass die alten Phoenix-Transaktionen nachträglich wieder akzeptiert werden. Nach Boreas stoppt das Mainnet bereits innerhalb der festgelegten Grenzen die Annahme neuer Phoenix-Transaktionen, aber die Knoten müssen weiterhin Historie dekodieren und ausführen können, um alte Blöcke zu synchronisieren und erneut abzuspielen.
Darum halte ich diese Fehlerbehandlungs-Verstärkung bei @Dusk für besonders wichtig: Sie schützt nicht nur einzelne Requests, sondern die tatsächliche Störungsreichweite im Netzwerk. Finanzielle Infrastruktur kann nicht garantieren, nie auf kaputte Daten zu stoßen—aber sie kann sicherstellen, dass kaputte Daten nur zu einer klaren Ablehnung führen und nicht unbeteiligte Nutzer gleich mit in den Ausfall hineinziehen.
@Dusk $DUSK #dusk